[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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/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
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>
For clarity, do you expect any existing use of
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
(or the new HVMMEM_unused) name should result in -EINVAL. What is
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

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

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
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


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. :)


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.





Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.