Re: [Xen-devel] [PATCH v10 3/6] x86/ioreq server: Add device model wrappers for new DMOP

[Yu Zhang <yu.c.zhang@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxx]
> > > > > > > Sent: 02 April 2017 13:24
> > > > > > > To: xen-devel@xxxxxxxxxxxxx
> > > > > > > Cc: zhiyuan.lv@xxxxxxxxx; Paul Durrant <Paul.Durrant@xxxxxxxxxx>; Ian
> > > > > > > Jackson <Ian.Jackson@xxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>
> > > > > > > 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@xxxxxxxxxxxxxxx>
> > > > > > Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > > > > >
> > > > > > ...with one observation...
> > > > > >
> > > > > > > ---
> > > > > > > Cc: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > > > > > > Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> > > > > > > Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
> > > > > > > ---
> > > > > > >     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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel