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

[Julien Grall <julien.grall@xxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel