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
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
