Re: [Xen-devel] [PATCH v3] xen: introduce VCPUOP_register_runstate_phys_memory_area hypercall

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.06.19 at 17:32, <andrii.anisov@xxxxxxxxx> wrote:
> On 17.06.19 09:28, Jan Beulich wrote:
>>> We may require existing runstate area unregistering if the system is aware
>>> of it. But it is for the new interface.
>>> The old one has no documentation about the unregistering. The implicit way
>>> is known to us, but not known to users.
>>> How to solve the clash?
>> 
>> And once again I'm not sure what to answer, considering that I've
>> already outlined a possible model (without any explicit unregistration).
> 
> Just to be sure, "the model" you are talking about is following:
> 
>> I thought it had been clarified already that normal guests can very
>> well use both interfaces, just not both at the same time: Boot loader
>> and OS could disagree in this regard, as the prime example.
> 
> Is it correct?

Not really - what you quote is a statement, not the outline of a
model. The basic idea for enforcement of a restriction was to
allow switching modes only when just one vCPU is online in a
guest.

> But with the current interface (VA) that model is already broken without 
> unregistration. On change between entities with different VA spaces the 
> hypervisor definitely has a chance to spoil the new VA space at the old 
> address.
> IMHO it should be fixed (at least documented) for the old interface.

Document - sure, feel free. Fix - I don't see how you would do
this. Every component handing control onto another one would
be in charge on its own. That's not under our control.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel