Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

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

On 4/28/2016 3:14 PM, Paul Durrant wrote:
> > -----Original Message-----
> > From: Yu, Zhang [mailto:yu.c.zhang@xxxxxxxxxxxxxxx]
> > Sent: 28 April 2016 03:47
> > To: Paul Durrant; George Dunlap
> > Cc: Kevin Tian; Wei Liu; Jun Nakajima; Andrew Cooper; Tim (Xen.org); xen-
> > devel@xxxxxxxxxxxxx; Zhiyuan Lv; Jan Beulich; Keir (Xen.org)
> > Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
> > Rename p2m_mmio_write_dm to p2m_ioreq_server.
> >
> >
> >
> > On 4/27/2016 10:42 PM, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: George Dunlap
> > > > Sent: 27 April 2016 15:13
> > > > To: Paul Durrant
> > > > Cc: Yu, Zhang; Jan Beulich; Kevin Tian; Wei Liu; Andrew Cooper; Tim
> > > > (Xen.org); xen-devel@xxxxxxxxxxxxx; Zhiyuan Lv; Jun Nakajima; Keir
> > (Xen.org)
> > > > Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
> > > > Rename p2m_mmio_write_dm to p2m_ioreq_server.
> > > >
> > > > On Mon, Apr 25, 2016 at 6:01 PM, Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> > > > wrote:
> > > > > For clarity, do you expect any existing use of
> > HVMMEM_mmio_write_dm
> > > > to continue to *function*? I agree that things should continue to build,
> > but if
> > > > they don't need to function then the now redundant p2m type should be
> > > > removed IMO and any attempt to set a page to
> > HVMMEM_mmio_write_dm
> > > > (or the new HVMMEM_unused) name should result in -EINVAL. What is
> > your
> > > > position on this?
> > > >
> > > > I sort of feel like we're playing some strange guessing game with the
> > > > color of this bike shed, where all 4 of us give a random combination
> > > > of constrants and then we have to figure out what the solution is. :-)
> > > >
> > > > There are two issues: the interface (HVMMEM_*) and the
> > > > internals.(p2m_*).
> > > >
> > > > Jan says that code that calls HVMOP_get_mem_type has to continue to
> > > > compile and function.  "Functioning" is easy, as you just don't return
> > > > that value and you're done.  Compiling just means having the #ifdef.
> > > >
> > > > It sounds like we all agree that HVMOP_set_mem_type with the current
> > > > HVMMEM_mmio_write_dm value should return -EINVAL.
> > > >
> > > > Regarding the p2m type which now should be impossible to set -- I
> > > > don't think it's critical to remove from the release, since it's just
> > > > internal.  I'd normally say just leave it for now to reduce code
> > > > churn.
> > > >
> > > > But mostly I think we just want to get this bike shed painted, so if
> > > > anyone thinks we should really remove the p2m type from this release,
> > > > then that's fine with me too (assuming it's OK with Wei).
> > > >
> > > > Does this cover everything?
> > > I think so. Thanks for the clarification.
> > >
> > > Yu, are you happy to submit a patch with the #ifdef in the header, and that
> > removes any ability to set the old type?
> > >
> > I'm fine with this, and thanks. :)
> > So my understanding is that the only difference between the new
> > patch and this current one is we do not replace p2m_mmio_write_dm
> > with p2m_ioreq_server, hence no need to introduce
> > HVMMEM_ioreq_server.
> > Is this understanding correct?
> I believe so. The main points are that:
>
> a) HVMMEM_mmio_write_dm no longer exists with the new interface version and is 
> replaced by HVMMEM_unused
> b) Any attempt to set a page to type HVMMEM_unused results in -EINVAL
Yep.

> > Besides, do you think it acceptable we just replace p2m_mmio_write_dm
> > with p2m_ioreq_server in next version, or should we remove this p2m
> > type and define p2m_ioreq_server with a different value? :)
> p2m_ioreq_server becomes defunct after the aforementioned patch. With that 
> patch applied there will be no way to set that type on a p2m entry so it should 
> be ok to re-use the type.
Got it. Thank you, Paul.
Will send the patch out later. :)

>   Paul
>
> > > I guess leaving the p2m type in place to avoid code churn is reasonable at
> > this stage, but anyone looking at the p2m code is probably going to question
> > why it's there in 4.7.
> > >   Paul
> > >
> > > >  -George
> > B.R.
> > Yu
Yu

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