| Message ID | 1491135867-623-4-git-send-email-yu.c.zhang@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> -----Original Message----- > From: Yu Zhang [mailto:yu.c.zhang@linux.intel.com] > Sent: 02 April 2017 13:24 > To: xen-devel@lists.xen.org > Cc: zhiyuan.lv@intel.com; Paul Durrant <Paul.Durrant@citrix.com>; Ian > Jackson <Ian.Jackson@citrix.com>; Wei Liu <wei.liu2@citrix.com> > Subject: [PATCH v10 3/6] x86/ioreq server: Add device model wrappers for > new DMOP > > A new device model wrapper is added for the newly introduced > DMOP - XEN_DMOP_map_mem_type_to_ioreq_server. > > Since currently this DMOP only supports the emulation of write > operations, attempts to trigger the DMOP with values other than > XEN_DMOP_IOREQ_MEM_ACCESS_WRITE or 0(to unmap the ioreq server) > shall fail. The wrapper shall be updated once read operations > are also to be emulated in the future. > > Also note currently this DMOP only supports one memory type, > and can be extended in the future to map multiple memory types > to multiple ioreq servers, e.g. mapping HVMMEM_ioreq_serverX to > ioreq server X, This wrapper shall be updated when such change > is made. > > Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> ...with one observation... > --- > Cc: Paul Durrant <paul.durrant@citrix.com> > Cc: Ian Jackson <ian.jackson@eu.citrix.com> > Cc: Wei Liu <wei.liu2@citrix.com> > --- > tools/libs/devicemodel/core.c | 25 > +++++++++++++++++++++++++ > tools/libs/devicemodel/include/xendevicemodel.h | 18 > ++++++++++++++++++ > tools/libs/devicemodel/libxendevicemodel.map | 1 + > tools/libxc/include/xenctrl_compat.h | 5 +++++ > tools/libxc/xc_devicemodel_compat.c | 17 +++++++++++++++++ This is new code so I don't think you really want compat code for this, do you? > 5 files changed, 66 insertions(+) > > diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c > index a85cb49..ff09819 100644 > --- a/tools/libs/devicemodel/core.c > +++ b/tools/libs/devicemodel/core.c > @@ -244,6 +244,31 @@ int > xendevicemodel_unmap_io_range_from_ioreq_server( > return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); > } > > +int xendevicemodel_map_mem_type_to_ioreq_server( > + xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, uint16_t > type, > + uint32_t flags) > +{ > + struct xen_dm_op op; > + struct xen_dm_op_map_mem_type_to_ioreq_server *data; > + > + if (type != HVMMEM_ioreq_server || > + flags & ~XEN_DMOP_IOREQ_MEM_ACCESS_WRITE) { > + errno = EINVAL; > + return -1; > + } > + > + memset(&op, 0, sizeof(op)); > + > + op.op = XEN_DMOP_map_mem_type_to_ioreq_server; > + data = &op.u.map_mem_type_to_ioreq_server; > + > + data->id = id; > + data->type = type; > + data->flags = flags; > + > + return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); > +} > + > int xendevicemodel_map_pcidev_to_ioreq_server( > xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, > uint16_t segment, uint8_t bus, uint8_t device, uint8_t function) > diff --git a/tools/libs/devicemodel/include/xendevicemodel.h > b/tools/libs/devicemodel/include/xendevicemodel.h > index b3f600e..1da216f 100644 > --- a/tools/libs/devicemodel/include/xendevicemodel.h > +++ b/tools/libs/devicemodel/include/xendevicemodel.h > @@ -104,6 +104,24 @@ int > xendevicemodel_unmap_io_range_from_ioreq_server( > uint64_t start, uint64_t end); > > /** > + * This function registers/deregisters a memory type for emulation. > + * > + * @parm dmod a handle to an open devicemodel interface. > + * @parm domid the domain id to be serviced. > + * @parm id the IOREQ Server id. > + * @parm type the memory type to be emulated. For now, only > HVMMEM_ioreq_server > + * is supported, and in the future new types can be introduced, e.g. > + * HVMMEM_ioreq_serverX mapped to ioreq server X. > + * @parm flags operations to be emulated; 0 for unmap. For now, only write > + * operations will be emulated and can be extended to emulate > + * read ones in the future. > + * @return 0 on success, -1 on failure. > + */ > +int xendevicemodel_map_mem_type_to_ioreq_server( > + xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, uint16_t > type, > + uint32_t flags); > + > +/** > * This function registers a PCI device for config space emulation. > * > * @parm dmod a handle to an open devicemodel interface. > diff --git a/tools/libs/devicemodel/libxendevicemodel.map > b/tools/libs/devicemodel/libxendevicemodel.map > index 45c773e..130222c 100644 > --- a/tools/libs/devicemodel/libxendevicemodel.map > +++ b/tools/libs/devicemodel/libxendevicemodel.map > @@ -5,6 +5,7 @@ VERS_1.0 { > xendevicemodel_get_ioreq_server_info; > xendevicemodel_map_io_range_to_ioreq_server; > xendevicemodel_unmap_io_range_from_ioreq_server; > + xendevicemodel_map_mem_type_to_ioreq_server; > xendevicemodel_map_pcidev_to_ioreq_server; > xendevicemodel_unmap_pcidev_from_ioreq_server; > xendevicemodel_destroy_ioreq_server; > diff --git a/tools/libxc/include/xenctrl_compat.h > b/tools/libxc/include/xenctrl_compat.h > index 040e7b2..173c08c 100644 > --- a/tools/libxc/include/xenctrl_compat.h > +++ b/tools/libxc/include/xenctrl_compat.h > @@ -134,6 +134,11 @@ int xc_hvm_map_io_range_to_ioreq_server( > int xc_hvm_unmap_io_range_from_ioreq_server( > xc_interface *xch, domid_t domid, ioservid_t id, int is_mmio, > uint64_t start, uint64_t end); > +int xc_hvm_map_mem_type_to_ioreq_server( > + xc_interface * xch, domid_t domid, ioservid_t id, > + uint16_t type, uint32_t flags); > +int xc_hvm_unmap_mem_type_from_ioreq_server( > + xc_interface * xch, domid_t domid, ioservid_t id, uint16_t type); > int xc_hvm_map_pcidev_to_ioreq_server( > xc_interface *xch, domid_t domid, ioservid_t id, uint16_t segment, > uint8_t bus, uint8_t device, uint8_t function); > diff --git a/tools/libxc/xc_devicemodel_compat.c > b/tools/libxc/xc_devicemodel_compat.c > index e4edeea..ea2496b 100644 > --- a/tools/libxc/xc_devicemodel_compat.c > +++ b/tools/libxc/xc_devicemodel_compat.c > @@ -41,6 +41,23 @@ int xc_hvm_unmap_io_range_from_ioreq_server( > start, end); > } > > +int xc_hvm_map_mem_type_to_ioreq_server( > + xc_interface *xch, domid_t domid, ioservid_t id, uint16_t type, > + uint32_t flags) > +{ > + return xendevicemodel_map_mem_type_to_ioreq_server(xch->dmod, > domid, > + id, type, > + flags); > +} > + > +int xc_hvm_unmap_mem_type_from_ioreq_server( > + xc_interface *xch, domid_t domid, ioservid_t id, uint16_t type) > +{ > + return xendevicemodel_map_mem_type_to_ioreq_server(xch->dmod, > domid, > + id, type, > + 0); > +} > + > int xc_hvm_map_pcidev_to_ioreq_server( > xc_interface *xch, domid_t domid, ioservid_t id, uint16_t segment, > uint8_t bus, uint8_t device, uint8_t function) > -- > 1.9.1
On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Yu Zhang [mailto:yu.c.zhang@linux.intel.com] > > Sent: 02 April 2017 13:24 > > To: xen-devel@lists.xen.org > > Cc: zhiyuan.lv@intel.com; Paul Durrant <Paul.Durrant@citrix.com>; Ian > > Jackson <Ian.Jackson@citrix.com>; Wei Liu <wei.liu2@citrix.com> > > Subject: [PATCH v10 3/6] x86/ioreq server: Add device model wrappers for > > new DMOP > > > > A new device model wrapper is added for the newly introduced > > DMOP - XEN_DMOP_map_mem_type_to_ioreq_server. > > > > Since currently this DMOP only supports the emulation of write > > operations, attempts to trigger the DMOP with values other than > > XEN_DMOP_IOREQ_MEM_ACCESS_WRITE or 0(to unmap the ioreq server) > > shall fail. The wrapper shall be updated once read operations > > are also to be emulated in the future. > > > > Also note currently this DMOP only supports one memory type, > > and can be extended in the future to map multiple memory types > > to multiple ioreq servers, e.g. mapping HVMMEM_ioreq_serverX to > > ioreq server X, This wrapper shall be updated when such change > > is made. > > > > Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> > > Reviewed-by: Paul Durrant <paul.durrant@citrix.com> > > ...with one observation... > > > --- > > Cc: Paul Durrant <paul.durrant@citrix.com> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com> > > Cc: Wei Liu <wei.liu2@citrix.com> > > --- > > tools/libs/devicemodel/core.c | 25 > > +++++++++++++++++++++++++ > > tools/libs/devicemodel/include/xendevicemodel.h | 18 > > ++++++++++++++++++ > > tools/libs/devicemodel/libxendevicemodel.map | 1 + > > tools/libxc/include/xenctrl_compat.h | 5 +++++ > > tools/libxc/xc_devicemodel_compat.c | 17 +++++++++++++++++ > > This is new code so I don't think you really want compat code for this, do you? Correct. No compat code is needed. Wei.
On 4/3/2017 5:28 PM, Wei Liu wrote: > On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote: >>> -----Original Message----- >>> From: Yu Zhang [mailto:yu.c.zhang@linux.intel.com] >>> Sent: 02 April 2017 13:24 >>> To: xen-devel@lists.xen.org >>> Cc: zhiyuan.lv@intel.com; Paul Durrant <Paul.Durrant@citrix.com>; Ian >>> Jackson <Ian.Jackson@citrix.com>; Wei Liu <wei.liu2@citrix.com> >>> Subject: [PATCH v10 3/6] x86/ioreq server: Add device model wrappers for >>> new DMOP >>> >>> A new device model wrapper is added for the newly introduced >>> DMOP - XEN_DMOP_map_mem_type_to_ioreq_server. >>> >>> Since currently this DMOP only supports the emulation of write >>> operations, attempts to trigger the DMOP with values other than >>> XEN_DMOP_IOREQ_MEM_ACCESS_WRITE or 0(to unmap the ioreq server) >>> shall fail. The wrapper shall be updated once read operations >>> are also to be emulated in the future. >>> >>> Also note currently this DMOP only supports one memory type, >>> and can be extended in the future to map multiple memory types >>> to multiple ioreq servers, e.g. mapping HVMMEM_ioreq_serverX to >>> ioreq server X, This wrapper shall be updated when such change >>> is made. >>> >>> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> >> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> >> >> ...with one observation... >> >>> --- >>> Cc: Paul Durrant <paul.durrant@citrix.com> >>> Cc: Ian Jackson <ian.jackson@eu.citrix.com> >>> Cc: Wei Liu <wei.liu2@citrix.com> >>> --- >>> tools/libs/devicemodel/core.c | 25 >>> +++++++++++++++++++++++++ >>> tools/libs/devicemodel/include/xendevicemodel.h | 18 >>> ++++++++++++++++++ >>> tools/libs/devicemodel/libxendevicemodel.map | 1 + >>> tools/libxc/include/xenctrl_compat.h | 5 +++++ >>> tools/libxc/xc_devicemodel_compat.c | 17 +++++++++++++++++ >> This is new code so I don't think you really want compat code for this, do you? > Correct. No compat code is needed. Thank you, Paul & Wei. Oh. I see, the compat code is only for existing ones. We do not need this. What about the libxendevicemodel.map? I updated this file to build pass for the libxc, with compat code not changed, maybe we shall not add the new op to libxendevicemodel.map either. I can send a V11 of this series - but must be quick to catch up the code freeze date. :) Or with other patches received "Reviewed by", we can just drop the useless code of this patch. Any suggestions? B.R. Yu > Wei. >
>>> On 05.04.17 at 08:53, <yu.c.zhang@linux.intel.com> wrote: > Or with other patches received "Reviewed by", we can just drop the > useless code of this patch. > Any suggestions? Without the libxc wrapper, the new DMOP is effectively dead code too. All or nothing, imo. Jan
On 4/5/2017 5:21 PM, Jan Beulich wrote: >>>> On 05.04.17 at 08:53, <yu.c.zhang@linux.intel.com> wrote: >> Or with other patches received "Reviewed by", we can just drop the >> useless code of this patch. >> Any suggestions? > Without the libxc wrapper, the new DMOP is effectively dead code > too. All or nothing, imo. Thanks Jan. But I am confused. :( Previously I thought the libxc needs to be updated together with libxendevicemodel. But from Paul & Wei's reply, and previous commit from Paul, my new understanding is that these libxc interfaces are only compatible code for old ones, and libxendevicemodel can be triggered, without through libxc interfaces. Is my new interpretation wrong? Thanks Yu > Jan > >
>>> On 05.04.17 at 11:22, <yu.c.zhang@linux.intel.com> wrote: > > On 4/5/2017 5:21 PM, Jan Beulich wrote: >>>>> On 05.04.17 at 08:53, <yu.c.zhang@linux.intel.com> wrote: >>> Or with other patches received "Reviewed by", we can just drop the >>> useless code of this patch. >>> Any suggestions? >> Without the libxc wrapper, the new DMOP is effectively dead code >> too. All or nothing, imo. > > Thanks Jan. But I am confused. :( > > Previously I thought the libxc needs to be updated together with > libxendevicemodel. > But from Paul & Wei's reply, and previous commit from Paul, my new > understanding > is that these libxc interfaces are only compatible code for old ones, > and libxendevicemodel > can be triggered, without through libxc interfaces. > > Is my new interpretation wrong? Oops, I'm sorry, I still have to get used to the split. I indeed meant "without the libxendevicemodel wrapper ..." Jan
On Wed, Apr 05, 2017 at 02:53:42PM +0800, Yu Zhang wrote: > > > On 4/3/2017 5:28 PM, Wei Liu wrote: > > On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote: > > > > -----Original Message----- > > > > From: Yu Zhang [mailto:yu.c.zhang@linux.intel.com] > > > > Sent: 02 April 2017 13:24 > > > > To: xen-devel@lists.xen.org > > > > Cc: zhiyuan.lv@intel.com; Paul Durrant <Paul.Durrant@citrix.com>; Ian > > > > Jackson <Ian.Jackson@citrix.com>; Wei Liu <wei.liu2@citrix.com> > > > > Subject: [PATCH v10 3/6] x86/ioreq server: Add device model wrappers for > > > > new DMOP > > > > > > > > A new device model wrapper is added for the newly introduced > > > > DMOP - XEN_DMOP_map_mem_type_to_ioreq_server. > > > > > > > > Since currently this DMOP only supports the emulation of write > > > > operations, attempts to trigger the DMOP with values other than > > > > XEN_DMOP_IOREQ_MEM_ACCESS_WRITE or 0(to unmap the ioreq server) > > > > shall fail. The wrapper shall be updated once read operations > > > > are also to be emulated in the future. > > > > > > > > Also note currently this DMOP only supports one memory type, > > > > and can be extended in the future to map multiple memory types > > > > to multiple ioreq servers, e.g. mapping HVMMEM_ioreq_serverX to > > > > ioreq server X, This wrapper shall be updated when such change > > > > is made. > > > > > > > > Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> > > > Reviewed-by: Paul Durrant <paul.durrant@citrix.com> > > > > > > ...with one observation... > > > > > > > --- > > > > Cc: Paul Durrant <paul.durrant@citrix.com> > > > > Cc: Ian Jackson <ian.jackson@eu.citrix.com> > > > > Cc: Wei Liu <wei.liu2@citrix.com> > > > > --- > > > > tools/libs/devicemodel/core.c | 25 > > > > +++++++++++++++++++++++++ > > > > tools/libs/devicemodel/include/xendevicemodel.h | 18 > > > > ++++++++++++++++++ > > > > tools/libs/devicemodel/libxendevicemodel.map | 1 + > > > > tools/libxc/include/xenctrl_compat.h | 5 +++++ > > > > tools/libxc/xc_devicemodel_compat.c | 17 +++++++++++++++++ > > > This is new code so I don't think you really want compat code for this, do you? > > Correct. No compat code is needed. > > Thank you, Paul & Wei. > Oh. I see, the compat code is only for existing ones. We do not need this. > What about the libxendevicemodel.map? I updated this file to build pass for > the libxc, with compat code > not changed, maybe we shall not add the new op to libxendevicemodel.map > either. > The modification to libxendevicemodel.map needs to stay. > I can send a V11 of this series - but must be quick to catch up the code > freeze date. :) > Or with other patches received "Reviewed by", we can just drop the useless > code of this patch. > Any suggestions? > Please drop the compat wrapper. Wei. > > B.R. > Yu > > > Wei. > > >
On Wed, Apr 05, 2017 at 11:08:46AM +0100, Wei Liu wrote: > On Wed, Apr 05, 2017 at 02:53:42PM +0800, Yu Zhang wrote: > > > > > > On 4/3/2017 5:28 PM, Wei Liu wrote: > > > On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote: > > > > > -----Original Message----- > > > > > From: Yu Zhang [mailto:yu.c.zhang@linux.intel.com] > > > > > Sent: 02 April 2017 13:24 > > > > > To: xen-devel@lists.xen.org > > > > > Cc: zhiyuan.lv@intel.com; Paul Durrant <Paul.Durrant@citrix.com>; Ian > > > > > Jackson <Ian.Jackson@citrix.com>; Wei Liu <wei.liu2@citrix.com> > > > > > Subject: [PATCH v10 3/6] x86/ioreq server: Add device model wrappers for > > > > > new DMOP > > > > > > > > > > A new device model wrapper is added for the newly introduced > > > > > DMOP - XEN_DMOP_map_mem_type_to_ioreq_server. > > > > > > > > > > Since currently this DMOP only supports the emulation of write > > > > > operations, attempts to trigger the DMOP with values other than > > > > > XEN_DMOP_IOREQ_MEM_ACCESS_WRITE or 0(to unmap the ioreq server) > > > > > shall fail. The wrapper shall be updated once read operations > > > > > are also to be emulated in the future. > > > > > > > > > > Also note currently this DMOP only supports one memory type, > > > > > and can be extended in the future to map multiple memory types > > > > > to multiple ioreq servers, e.g. mapping HVMMEM_ioreq_serverX to > > > > > ioreq server X, This wrapper shall be updated when such change > > > > > is made. > > > > > > > > > > Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> > > > > Reviewed-by: Paul Durrant <paul.durrant@citrix.com> > > > > > > > > ...with one observation... > > > > > > > > > --- > > > > > Cc: Paul Durrant <paul.durrant@citrix.com> > > > > > Cc: Ian Jackson <ian.jackson@eu.citrix.com> > > > > > Cc: Wei Liu <wei.liu2@citrix.com> > > > > > --- > > > > > tools/libs/devicemodel/core.c | 25 > > > > > +++++++++++++++++++++++++ > > > > > tools/libs/devicemodel/include/xendevicemodel.h | 18 > > > > > ++++++++++++++++++ > > > > > tools/libs/devicemodel/libxendevicemodel.map | 1 + > > > > > tools/libxc/include/xenctrl_compat.h | 5 +++++ > > > > > tools/libxc/xc_devicemodel_compat.c | 17 +++++++++++++++++ > > > > This is new code so I don't think you really want compat code for this, do you? > > > Correct. No compat code is needed. > > > > Thank you, Paul & Wei. > > Oh. I see, the compat code is only for existing ones. We do not need this. > > What about the libxendevicemodel.map? I updated this file to build pass for > > the libxc, with compat code > > not changed, maybe we shall not add the new op to libxendevicemodel.map > > either. > > > > The modification to libxendevicemodel.map needs to stay. > And, if you're interested in the rationale behind this. https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf Wei.
On 4/5/2017 6:08 PM, Wei Liu wrote: > On Wed, Apr 05, 2017 at 02:53:42PM +0800, Yu Zhang wrote: >> >> On 4/3/2017 5:28 PM, Wei Liu wrote: >>> On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote: >>>>> -----Original Message----- >>>>> From: Yu Zhang [mailto:yu.c.zhang@linux.intel.com] >>>>> Sent: 02 April 2017 13:24 >>>>> To: xen-devel@lists.xen.org >>>>> Cc: zhiyuan.lv@intel.com; Paul Durrant <Paul.Durrant@citrix.com>; Ian >>>>> Jackson <Ian.Jackson@citrix.com>; Wei Liu <wei.liu2@citrix.com> >>>>> Subject: [PATCH v10 3/6] x86/ioreq server: Add device model wrappers for >>>>> new DMOP >>>>> >>>>> A new device model wrapper is added for the newly introduced >>>>> DMOP - XEN_DMOP_map_mem_type_to_ioreq_server. >>>>> >>>>> Since currently this DMOP only supports the emulation of write >>>>> operations, attempts to trigger the DMOP with values other than >>>>> XEN_DMOP_IOREQ_MEM_ACCESS_WRITE or 0(to unmap the ioreq server) >>>>> shall fail. The wrapper shall be updated once read operations >>>>> are also to be emulated in the future. >>>>> >>>>> Also note currently this DMOP only supports one memory type, >>>>> and can be extended in the future to map multiple memory types >>>>> to multiple ioreq servers, e.g. mapping HVMMEM_ioreq_serverX to >>>>> ioreq server X, This wrapper shall be updated when such change >>>>> is made. >>>>> >>>>> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> >>>> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> >>>> >>>> ...with one observation... >>>> >>>>> --- >>>>> Cc: Paul Durrant <paul.durrant@citrix.com> >>>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com> >>>>> Cc: Wei Liu <wei.liu2@citrix.com> >>>>> --- >>>>> tools/libs/devicemodel/core.c | 25 >>>>> +++++++++++++++++++++++++ >>>>> tools/libs/devicemodel/include/xendevicemodel.h | 18 >>>>> ++++++++++++++++++ >>>>> tools/libs/devicemodel/libxendevicemodel.map | 1 + >>>>> tools/libxc/include/xenctrl_compat.h | 5 +++++ >>>>> tools/libxc/xc_devicemodel_compat.c | 17 +++++++++++++++++ >>>> This is new code so I don't think you really want compat code for this, do you? >>> Correct. No compat code is needed. >> Thank you, Paul & Wei. >> Oh. I see, the compat code is only for existing ones. We do not need this. >> What about the libxendevicemodel.map? I updated this file to build pass for >> the libxc, with compat code >> not changed, maybe we shall not add the new op to libxendevicemodel.map >> either. >> > The modification to libxendevicemodel.map needs to stay. > >> I can send a V11 of this series - but must be quick to catch up the code >> freeze date. :) >> Or with other patches received "Reviewed by", we can just drop the useless >> code of this patch. >> Any suggestions? >> > Please drop the compat wrapper. Thank you, Wei. So this series is OK for merge. And with compat wrapper dropped while committing, we do not need send the V11, right? B.R. Yu > Wei. > >> B.R. >> Yu >> >>> Wei. >>>
On 4/5/2017 6:20 PM, Wei Liu wrote: > On Wed, Apr 05, 2017 at 11:08:46AM +0100, Wei Liu wrote: >> On Wed, Apr 05, 2017 at 02:53:42PM +0800, Yu Zhang wrote: >>> >>> On 4/3/2017 5:28 PM, Wei Liu wrote: >>>> On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote: >>>>>> -----Original Message----- >>>>>> From: Yu Zhang [mailto:yu.c.zhang@linux.intel.com] >>>>>> Sent: 02 April 2017 13:24 >>>>>> To: xen-devel@lists.xen.org >>>>>> Cc: zhiyuan.lv@intel.com; Paul Durrant <Paul.Durrant@citrix.com>; Ian >>>>>> Jackson <Ian.Jackson@citrix.com>; Wei Liu <wei.liu2@citrix.com> >>>>>> Subject: [PATCH v10 3/6] x86/ioreq server: Add device model wrappers for >>>>>> new DMOP >>>>>> >>>>>> A new device model wrapper is added for the newly introduced >>>>>> DMOP - XEN_DMOP_map_mem_type_to_ioreq_server. >>>>>> >>>>>> Since currently this DMOP only supports the emulation of write >>>>>> operations, attempts to trigger the DMOP with values other than >>>>>> XEN_DMOP_IOREQ_MEM_ACCESS_WRITE or 0(to unmap the ioreq server) >>>>>> shall fail. The wrapper shall be updated once read operations >>>>>> are also to be emulated in the future. >>>>>> >>>>>> Also note currently this DMOP only supports one memory type, >>>>>> and can be extended in the future to map multiple memory types >>>>>> to multiple ioreq servers, e.g. mapping HVMMEM_ioreq_serverX to >>>>>> ioreq server X, This wrapper shall be updated when such change >>>>>> is made. >>>>>> >>>>>> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> >>>>> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> >>>>> >>>>> ...with one observation... >>>>> >>>>>> --- >>>>>> Cc: Paul Durrant <paul.durrant@citrix.com> >>>>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com> >>>>>> Cc: Wei Liu <wei.liu2@citrix.com> >>>>>> --- >>>>>> tools/libs/devicemodel/core.c | 25 >>>>>> +++++++++++++++++++++++++ >>>>>> tools/libs/devicemodel/include/xendevicemodel.h | 18 >>>>>> ++++++++++++++++++ >>>>>> tools/libs/devicemodel/libxendevicemodel.map | 1 + >>>>>> tools/libxc/include/xenctrl_compat.h | 5 +++++ >>>>>> tools/libxc/xc_devicemodel_compat.c | 17 +++++++++++++++++ >>>>> This is new code so I don't think you really want compat code for this, do you? >>>> Correct. No compat code is needed. >>> Thank you, Paul & Wei. >>> Oh. I see, the compat code is only for existing ones. We do not need this. >>> What about the libxendevicemodel.map? I updated this file to build pass for >>> the libxc, with compat code >>> not changed, maybe we shall not add the new op to libxendevicemodel.map >>> either. >>> >> The modification to libxendevicemodel.map needs to stay. >> > And, if you're interested in the rationale behind this. > > https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf Wah. Great! Thanks for your information! :) Yu > Wei. >
On 4/5/2017 6:33 PM, Wei Liu wrote: > On Wed, Apr 05, 2017 at 06:21:16PM +0800, Yu Zhang wrote: >> >> On 4/5/2017 6:08 PM, Wei Liu wrote: >>> On Wed, Apr 05, 2017 at 02:53:42PM +0800, Yu Zhang wrote: >>>> On 4/3/2017 5:28 PM, Wei Liu wrote: >>>>> On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote: >>>>>>> -----Original Message----- >>>>>>> From: Yu Zhang [mailto:yu.c.zhang@linux.intel.com] >>>>>>> Sent: 02 April 2017 13:24 >>>>>>> To: xen-devel@lists.xen.org >>>>>>> Cc: zhiyuan.lv@intel.com; Paul Durrant <Paul.Durrant@citrix.com>; Ian >>>>>>> Jackson <Ian.Jackson@citrix.com>; Wei Liu <wei.liu2@citrix.com> >>>>>>> Subject: [PATCH v10 3/6] x86/ioreq server: Add device model wrappers for >>>>>>> new DMOP >>>>>>> >>>>>>> A new device model wrapper is added for the newly introduced >>>>>>> DMOP - XEN_DMOP_map_mem_type_to_ioreq_server. >>>>>>> >>>>>>> Since currently this DMOP only supports the emulation of write >>>>>>> operations, attempts to trigger the DMOP with values other than >>>>>>> XEN_DMOP_IOREQ_MEM_ACCESS_WRITE or 0(to unmap the ioreq server) >>>>>>> shall fail. The wrapper shall be updated once read operations >>>>>>> are also to be emulated in the future. >>>>>>> >>>>>>> Also note currently this DMOP only supports one memory type, >>>>>>> and can be extended in the future to map multiple memory types >>>>>>> to multiple ioreq servers, e.g. mapping HVMMEM_ioreq_serverX to >>>>>>> ioreq server X, This wrapper shall be updated when such change >>>>>>> is made. >>>>>>> >>>>>>> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> >>>>>> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> >>>>>> >>>>>> ...with one observation... >>>>>> >>>>>>> --- >>>>>>> Cc: Paul Durrant <paul.durrant@citrix.com> >>>>>>> Cc: Ian Jackson <ian.jackson@eu.citrix.com> >>>>>>> Cc: Wei Liu <wei.liu2@citrix.com> >>>>>>> --- >>>>>>> tools/libs/devicemodel/core.c | 25 >>>>>>> +++++++++++++++++++++++++ >>>>>>> tools/libs/devicemodel/include/xendevicemodel.h | 18 >>>>>>> ++++++++++++++++++ >>>>>>> tools/libs/devicemodel/libxendevicemodel.map | 1 + >>>>>>> tools/libxc/include/xenctrl_compat.h | 5 +++++ >>>>>>> tools/libxc/xc_devicemodel_compat.c | 17 +++++++++++++++++ >>>>>> This is new code so I don't think you really want compat code for this, do you? >>>>> Correct. No compat code is needed. >>>> Thank you, Paul & Wei. >>>> Oh. I see, the compat code is only for existing ones. We do not need this. >>>> What about the libxendevicemodel.map? I updated this file to build pass for >>>> the libxc, with compat code >>>> not changed, maybe we shall not add the new op to libxendevicemodel.map >>>> either. >>>> >>> The modification to libxendevicemodel.map needs to stay. >>> >>>> I can send a V11 of this series - but must be quick to catch up the code >>>> freeze date. :) >>>> Or with other patches received "Reviewed by", we can just drop the useless >>>> code of this patch. >>>> Any suggestions? >>>> >>> Please drop the compat wrapper. >> Thank you, Wei. >> So this series is OK for merge. And with compat wrapper dropped while >> committing, >> we do not need send the V11, right? >> > Assuming Jan is happy with the HV code as-is. Yes, I can drop that hunk > and commit this series. Thanks, Wei. Jan, can we reach consensus on this? :) Yu > Wei. > >> B.R. >> Yu >> >>> Wei. >>> >>>> B.R. >>>> Yu >>>> >>>>> Wei. >>>>>
On Wed, Apr 05, 2017 at 06:21:16PM +0800, Yu Zhang wrote: > > > On 4/5/2017 6:08 PM, Wei Liu wrote: > > On Wed, Apr 05, 2017 at 02:53:42PM +0800, Yu Zhang wrote: > > > > > > On 4/3/2017 5:28 PM, Wei Liu wrote: > > > > On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote: > > > > > > -----Original Message----- > > > > > > From: Yu Zhang [mailto:yu.c.zhang@linux.intel.com] > > > > > > Sent: 02 April 2017 13:24 > > > > > > To: xen-devel@lists.xen.org > > > > > > Cc: zhiyuan.lv@intel.com; Paul Durrant <Paul.Durrant@citrix.com>; Ian > > > > > > Jackson <Ian.Jackson@citrix.com>; Wei Liu <wei.liu2@citrix.com> > > > > > > Subject: [PATCH v10 3/6] x86/ioreq server: Add device model wrappers for > > > > > > new DMOP > > > > > > > > > > > > A new device model wrapper is added for the newly introduced > > > > > > DMOP - XEN_DMOP_map_mem_type_to_ioreq_server. > > > > > > > > > > > > Since currently this DMOP only supports the emulation of write > > > > > > operations, attempts to trigger the DMOP with values other than > > > > > > XEN_DMOP_IOREQ_MEM_ACCESS_WRITE or 0(to unmap the ioreq server) > > > > > > shall fail. The wrapper shall be updated once read operations > > > > > > are also to be emulated in the future. > > > > > > > > > > > > Also note currently this DMOP only supports one memory type, > > > > > > and can be extended in the future to map multiple memory types > > > > > > to multiple ioreq servers, e.g. mapping HVMMEM_ioreq_serverX to > > > > > > ioreq server X, This wrapper shall be updated when such change > > > > > > is made. > > > > > > > > > > > > Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> > > > > > Reviewed-by: Paul Durrant <paul.durrant@citrix.com> > > > > > > > > > > ...with one observation... > > > > > > > > > > > --- > > > > > > Cc: Paul Durrant <paul.durrant@citrix.com> > > > > > > Cc: Ian Jackson <ian.jackson@eu.citrix.com> > > > > > > Cc: Wei Liu <wei.liu2@citrix.com> > > > > > > --- > > > > > > tools/libs/devicemodel/core.c | 25 > > > > > > +++++++++++++++++++++++++ > > > > > > tools/libs/devicemodel/include/xendevicemodel.h | 18 > > > > > > ++++++++++++++++++ > > > > > > tools/libs/devicemodel/libxendevicemodel.map | 1 + > > > > > > tools/libxc/include/xenctrl_compat.h | 5 +++++ > > > > > > tools/libxc/xc_devicemodel_compat.c | 17 +++++++++++++++++ > > > > > This is new code so I don't think you really want compat code for this, do you? > > > > Correct. No compat code is needed. > > > Thank you, Paul & Wei. > > > Oh. I see, the compat code is only for existing ones. We do not need this. > > > What about the libxendevicemodel.map? I updated this file to build pass for > > > the libxc, with compat code > > > not changed, maybe we shall not add the new op to libxendevicemodel.map > > > either. > > > > > The modification to libxendevicemodel.map needs to stay. > > > > > I can send a V11 of this series - but must be quick to catch up the code > > > freeze date. :) > > > Or with other patches received "Reviewed by", we can just drop the useless > > > code of this patch. > > > Any suggestions? > > > > > Please drop the compat wrapper. > > Thank you, Wei. > So this series is OK for merge. And with compat wrapper dropped while > committing, > we do not need send the V11, right? > Assuming Jan is happy with the HV code as-is. Yes, I can drop that hunk and commit this series. Wei. > B.R. > Yu > > > Wei. > > > > > B.R. > > > Yu > > > > > > > Wei. > > > > >
>>> On 05.04.17 at 12:26, <yu.c.zhang@linux.intel.com> wrote: > On 4/5/2017 6:33 PM, Wei Liu wrote: >> On Wed, Apr 05, 2017 at 06:21:16PM +0800, Yu Zhang wrote: >>> So this series is OK for merge. And with compat wrapper dropped while >>> committing, >>> we do not need send the V11, right? >>> >> Assuming Jan is happy with the HV code as-is. Yes, I can drop that hunk >> and commit this series. > > Thanks, Wei. > Jan, can we reach consensus on this? :) As mentioned on irc, there are still some missing acks for some of the patches. Jan
On 4/5/2017 6:46 PM, Jan Beulich wrote: >>>> On 05.04.17 at 12:26, <yu.c.zhang@linux.intel.com> wrote: >> On 4/5/2017 6:33 PM, Wei Liu wrote: >>> On Wed, Apr 05, 2017 at 06:21:16PM +0800, Yu Zhang wrote: >>>> So this series is OK for merge. And with compat wrapper dropped while >>>> committing, >>>> we do not need send the V11, right? >>>> >>> Assuming Jan is happy with the HV code as-is. Yes, I can drop that hunk >>> and commit this series. >> Thanks, Wei. >> Jan, can we reach consensus on this? :) > As mentioned on irc, there are still some missing acks for some of > the patches. Yeah, thanks Jan. Guess you mean George's. May god bless... :) Yu > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel
diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c index a85cb49..ff09819 100644 --- a/tools/libs/devicemodel/core.c +++ b/tools/libs/devicemodel/core.c @@ -244,6 +244,31 @@ int xendevicemodel_unmap_io_range_from_ioreq_server( return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); } +int xendevicemodel_map_mem_type_to_ioreq_server( + xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, uint16_t type, + uint32_t flags) +{ + struct xen_dm_op op; + struct xen_dm_op_map_mem_type_to_ioreq_server *data; + + if (type != HVMMEM_ioreq_server || + flags & ~XEN_DMOP_IOREQ_MEM_ACCESS_WRITE) { + errno = EINVAL; + return -1; + } + + memset(&op, 0, sizeof(op)); + + op.op = XEN_DMOP_map_mem_type_to_ioreq_server; + data = &op.u.map_mem_type_to_ioreq_server; + + data->id = id; + data->type = type; + data->flags = flags; + + return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); +} + int xendevicemodel_map_pcidev_to_ioreq_server( xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, uint16_t segment, uint8_t bus, uint8_t device, uint8_t function) diff --git a/tools/libs/devicemodel/include/xendevicemodel.h b/tools/libs/devicemodel/include/xendevicemodel.h index b3f600e..1da216f 100644 --- a/tools/libs/devicemodel/include/xendevicemodel.h +++ b/tools/libs/devicemodel/include/xendevicemodel.h @@ -104,6 +104,24 @@ int xendevicemodel_unmap_io_range_from_ioreq_server( uint64_t start, uint64_t end); /** + * This function registers/deregisters a memory type for emulation. + * + * @parm dmod a handle to an open devicemodel interface. + * @parm domid the domain id to be serviced. + * @parm id the IOREQ Server id. + * @parm type the memory type to be emulated. For now, only HVMMEM_ioreq_server + * is supported, and in the future new types can be introduced, e.g. + * HVMMEM_ioreq_serverX mapped to ioreq server X. + * @parm flags operations to be emulated; 0 for unmap. For now, only write + * operations will be emulated and can be extended to emulate + * read ones in the future. + * @return 0 on success, -1 on failure. + */ +int xendevicemodel_map_mem_type_to_ioreq_server( + xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, uint16_t type, + uint32_t flags); + +/** * This function registers a PCI device for config space emulation. * * @parm dmod a handle to an open devicemodel interface. diff --git a/tools/libs/devicemodel/libxendevicemodel.map b/tools/libs/devicemodel/libxendevicemodel.map index 45c773e..130222c 100644 --- a/tools/libs/devicemodel/libxendevicemodel.map +++ b/tools/libs/devicemodel/libxendevicemodel.map @@ -5,6 +5,7 @@ VERS_1.0 { xendevicemodel_get_ioreq_server_info; xendevicemodel_map_io_range_to_ioreq_server; xendevicemodel_unmap_io_range_from_ioreq_server; + xendevicemodel_map_mem_type_to_ioreq_server; xendevicemodel_map_pcidev_to_ioreq_server; xendevicemodel_unmap_pcidev_from_ioreq_server; xendevicemodel_destroy_ioreq_server; diff --git a/tools/libxc/include/xenctrl_compat.h b/tools/libxc/include/xenctrl_compat.h index 040e7b2..173c08c 100644 --- a/tools/libxc/include/xenctrl_compat.h +++ b/tools/libxc/include/xenctrl_compat.h @@ -134,6 +134,11 @@ int xc_hvm_map_io_range_to_ioreq_server( int xc_hvm_unmap_io_range_from_ioreq_server( xc_interface *xch, domid_t domid, ioservid_t id, int is_mmio, uint64_t start, uint64_t end); +int xc_hvm_map_mem_type_to_ioreq_server( + xc_interface * xch, domid_t domid, ioservid_t id, + uint16_t type, uint32_t flags); +int xc_hvm_unmap_mem_type_from_ioreq_server( + xc_interface * xch, domid_t domid, ioservid_t id, uint16_t type); int xc_hvm_map_pcidev_to_ioreq_server( xc_interface *xch, domid_t domid, ioservid_t id, uint16_t segment, uint8_t bus, uint8_t device, uint8_t function); diff --git a/tools/libxc/xc_devicemodel_compat.c b/tools/libxc/xc_devicemodel_compat.c index e4edeea..ea2496b 100644 --- a/tools/libxc/xc_devicemodel_compat.c +++ b/tools/libxc/xc_devicemodel_compat.c @@ -41,6 +41,23 @@ int xc_hvm_unmap_io_range_from_ioreq_server( start, end); } +int xc_hvm_map_mem_type_to_ioreq_server( + xc_interface *xch, domid_t domid, ioservid_t id, uint16_t type, + uint32_t flags) +{ + return xendevicemodel_map_mem_type_to_ioreq_server(xch->dmod, domid, + id, type, + flags); +} + +int xc_hvm_unmap_mem_type_from_ioreq_server( + xc_interface *xch, domid_t domid, ioservid_t id, uint16_t type) +{ + return xendevicemodel_map_mem_type_to_ioreq_server(xch->dmod, domid, + id, type, + 0); +} + int xc_hvm_map_pcidev_to_ioreq_server( xc_interface *xch, domid_t domid, ioservid_t id, uint16_t segment, uint8_t bus, uint8_t device, uint8_t function)
A new device model wrapper is added for the newly introduced DMOP - XEN_DMOP_map_mem_type_to_ioreq_server. Since currently this DMOP only supports the emulation of write operations, attempts to trigger the DMOP with values other than XEN_DMOP_IOREQ_MEM_ACCESS_WRITE or 0(to unmap the ioreq server) shall fail. The wrapper shall be updated once read operations are also to be emulated in the future. Also note currently this DMOP only supports one memory type, and can be extended in the future to map multiple memory types to multiple ioreq servers, e.g. mapping HVMMEM_ioreq_serverX to ioreq server X, This wrapper shall be updated when such change is made. Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> --- Cc: Paul Durrant <paul.durrant@citrix.com> Cc: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Wei Liu <wei.liu2@citrix.com> --- tools/libs/devicemodel/core.c | 25 +++++++++++++++++++++++++ tools/libs/devicemodel/include/xendevicemodel.h | 18 ++++++++++++++++++ tools/libs/devicemodel/libxendevicemodel.map | 1 + tools/libxc/include/xenctrl_compat.h | 5 +++++ tools/libxc/xc_devicemodel_compat.c | 17 +++++++++++++++++ 5 files changed, 66 insertions(+)