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

> -----Original Message-----
> From: George Dunlap
> Sent: 25 April 2016 15:28
> To: Paul Durrant
> Cc: Jan Beulich; Kevin Tian; Wei Liu; Andrew Cooper; Tim (Xen.org); xen-
> devel@xxxxxxxxxxxxx; Yu Zhang; 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 3:19 PM, Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> wrote:
> >> -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 25 April 2016 15:16
> >> To: Paul Durrant
> >> Cc: Andrew Cooper; George Dunlap; Wei Liu; Jun Nakajima; Kevin Tian;
> >> Zhiyuan Lv; Yu Zhang; xen-devel@xxxxxxxxxxxxx; Keir (Xen.org); Tim
> (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 25.04.16 at 16:01, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> > The p2m type changes are also wrong. That type needs to be left alone,
> >> > presumably, so that anything using HVMMEM_mmio_write_dm and
> >> compiled to the
> >> > old interface version continues to function. I think
> HVMMEM_ioreq_server
> >> > needs to map to a new p2m type which should be introduced in patch
> #3.
> >>
> >> I don't understand this part: I thought it was agreed that the old
> >> p2m type needs to go away (not the least because we're tight on
> >> these), and use of the old HVMMEM_* type needs to result in
> >> errors.
> >>
> >
> > I may have misunderstood. I thought we'd back-tracked on that because
> there's a concern that we also need to keep anything compiled against the
> old header working. If not then this patch should also remove that p2m type,
> not rename it.
> You mean remove the old HVMMEM type?
> There are two issues:
> 1. Whether old code should continue to compile
> 2. How old code should act on new hypervisors
> I think we've determined that we definitely cannot allow code compiled
> against old hypervisors to accidentally use a different p2m type; so
> we certainly need to "burn" an enum here.
> I'd personally prefer we just straight-up rename it to HVMMEM_unused,
> so nobody continues to think that the HVMMEM_mmio_write_dm
> functionality might still actually work; I think Jan thinks that's not
> allowed.
> Honestly I don't see the point of letting it compile and then return
> -EINVAL when we run it.  If people complain that it doesn't work
> anymore we should either make it compile *and* maintain the
> functionality, or say "Sorry, just use an older version" and make it
> neither compile nor maintain the functionality.
> But I sort of assumed this discussion on what support looked like had
> already been had and Jan was just enforcing it.
> (Maybe we should have had a talk about this in person at the Hackathon...)

I'm now confused as to what was agreed, if anything.

The fact of the matter is though that the old type escaped into the wild. I 
wanted it to go away but because it escaped I guess that may just not be 


>  -George
Xen-devel mailing list



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