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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Apr 27, 2016 at 03:12:46PM +0100, George Dunlap wrote:
> 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.
> 

This, is the most urgent issue at the moment AIUI.

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

I would prefer as few churns as possible.

Wei.

> Does this cover everything?
> 
>  -George

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