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

  Paul

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

 


Rackspace

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