On 14/05/2019 14:05, Andrii Anisov wrote:
On 14.05.19 15:02, Jan Beulich wrote:
Well, I think Julian's implication was that we can't support in particular
the boot loader -> kernel handover case without extra measures (if
at all), and hence he added things together and said what results
from this. Of course ideally we'd reject mixed requests, but unless
someone can come up with a clever means of how to determine entity
boundaries I'm afraid this is not going to be possible without breaking
certain setups.
From my understanding, if we are speaking of different entities in a domain and
their boundaries, we have to define unregister interface as well. So that those
entities would be able to take care of themselves explicitly.
You have to keep in mind that existing OS have to run on newer Xen without any
modification.
The existing hypercall allows you to:
1) De-register an interface using the value 0.
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.
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). 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.
2) should not be too difficult to implement. It is just a matter of clean-up
whatever was used previous before registering the new interface.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
