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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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

 -George

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