[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |