Re: [Xen-devel] [PATCH v2 2/2] xen: implement VCPUOP_register_runstate_phys_memory_area

[Andrii Anisov <andrii.anisov@xxxxxxxxx>]

On 14.05.19 16:49, Julien Grall wrote:
> You have to keep in mind that existing OS have to run on newer Xen without any 
> modification.
As I just written to Jan, it is one more reason to keep those interfaces living 
in parallel and do not mix their implementation.

> The existing hypercall allows you to:
>     1) De-register an interface using the value 0.
My current implementation can easily be updated with the same behavior.

>     2) Replacing a current existing interface
> You probably can't use 2) for a bootloader -> kernel handover because we are 
> dealing with guest virtual address. There is an high chance the virtual address 
> space layout is going to be different or even turning off MMU for a bit (done on 
> Arm). So you have to use 1) otherwise you might write in a random place in memory.
This definitely not the way to handle transitions between systems in a guest 
domain.

> I am not entirely sure whether there are actual value for 2). The only reason I 
> can think of is if you want to move around the runstate in your virtual address 
> space. But that's sounds a bit weird at least on Arm.
> For the new hypercall, I think we at least want 1) (with a magic value TBD). 
The magic value 0x0 can easily be introduced.

>  2) might be helpful in the case the bootloader didn't do the right thing or we 
> are using Kexec to boot a new kernel. This would also be safer as physical 
> address could be excluded more easily.
But the new system have to get some knowledge about the previous phys addr is 
reserved (used by hypervisor), and do not use it prior to registering new 
runstate area.
Providing such a knowledge is something (e.g.) the bootloader should take care 
of. But, IMO, it is better to require from (e.g.) the bootloader to unregister 
its runstate area prior to switching to the new system.

--
Sincerely,
Andrii Anisov.

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