Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 25 Jul 2023 12:39:14 +0530
From:   Viresh Kumar <viresh.kumar@linaro.org>
To:     Jan Beulich <jbeulich@suse.com>
Cc:     Vincent Guittot <vincent.guittot@linaro.org>,
        Alex =?utf-8?Q?Benn=C3=A9e?= <alex.bennee@linaro.org>,
        stratos-dev@op-lists.linaro.org,
        Erik Schilling <erik.schilling@linaro.org>,
        Manos Pitsidianakis <manos.pitsidianakis@linaro.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
        Juergen Gross <jgross@suse.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: Re: [PATCH V3 1/2] xen: Update dm_op.h from Xen public header
Message-ID: <20230725070914.m3dxlokedrgjlgcu@vireshk-i7>
References: <ffae9d7021829fea19fd93fda3c30b52b0af923e.1690190453.git.viresh.kumar@linaro.org>
 <1498bef6-ded0-1b1f-a5ca-e8755800b489@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1498bef6-ded0-1b1f-a5ca-e8755800b489@suse.com>
Precedence: bulk

On 25-07-23, 09:04, Jan Beulich wrote:
> On 25.07.2023 08:47, Viresh Kumar wrote:
> > +struct xen_dm_op {
> > +    uint32_t op;
> > +    uint32_t pad;
> > +    union {
> > +        struct xen_dm_op_create_ioreq_server create_ioreq_server;
> > +        struct xen_dm_op_get_ioreq_server_info get_ioreq_server_info;
> > +        struct xen_dm_op_ioreq_server_range map_io_range_to_ioreq_server;
> > +        struct xen_dm_op_ioreq_server_range unmap_io_range_from_ioreq_server;
> > +        struct xen_dm_op_set_ioreq_server_state set_ioreq_server_state;
> > +        struct xen_dm_op_destroy_ioreq_server destroy_ioreq_server;
> > +        struct xen_dm_op_track_dirty_vram track_dirty_vram;
> > +        struct xen_dm_op_set_pci_intx_level set_pci_intx_level;
> > +        struct xen_dm_op_set_isa_irq_level set_isa_irq_level;
> > +        struct xen_dm_op_set_irq_level set_irq_level;
> > +        struct xen_dm_op_set_pci_link_route set_pci_link_route;
> > +        struct xen_dm_op_modified_memory modified_memory;
> > +        struct xen_dm_op_set_mem_type set_mem_type;
> > +        struct xen_dm_op_inject_event inject_event;
> > +        struct xen_dm_op_inject_msi inject_msi;
> > +        struct xen_dm_op_map_mem_type_to_ioreq_server map_mem_type_to_ioreq_server;
> > +        struct xen_dm_op_remote_shutdown remote_shutdown;
> > +        struct xen_dm_op_relocate_memory relocate_memory;
> > +        struct xen_dm_op_pin_memory_cacheattr pin_memory_cacheattr;
> > +        struct xen_dm_op_nr_vcpus nr_vcpus;
> > +    } u;
> > +};
> 
> Is sync-ing for the sake of sync-ing really useful? For example, are any
> of the ioreq server elements halfway likely to ever be used in the kernel?

The only field, out of the union, I am using for now is:

        struct xen_dm_op_set_irq_level set_irq_level;

I am not sure if some of the others are going to be used or not in the
future.

FWIW, I am also looking at solving a similar problem for Ioeventfds
(kick from guest to backend) and may end up using a few more of these.
But they can very well be contained in that patchset.

-- 
viresh