Re: [Xen-devel] RT Xen on ARM - R-Car series

[Andrii Anisov <andrii.anisov@xxxxxxxxx>]

Hello Roger,

Sorry for a delayed response.

On 07.02.19 12:35, Roger Pau Monné wrote:
> I've been thinking about this with other Citrix folks, and I'm not
> sure the proposed patch is a good solution. It's not possible for us
> to know whether there's a kernel somewhere relying on changing the
> virtual address of the runtime state area without issuing a new
> hypercall.
Do you mean allocating another buffer by VM and mapping it to a virtual address 
known to XEN? Or remapping existing buffer to a different virtual address?

> If such kernel existed by making this change we would introduce random
> memory corruption to that kernel, which would be very hard to track
> and considered a regression.
I guess you actually mean that VM is trying to map another physical buffer to a 
vaddr known to XEN. As I said here [1], even current implementation looks 
problematic, because VM's changes in PT are not atomic from the hypervisor 
point of view.
I stated that for ARM, but x86 does not seem to differ here.

Actually VM trying to make changes behind a hypervisor's back is a really bad 
idea. Because the hypervisor *is* always behind the VM's back.

> I think the best way to move forward is to pick my patch and introduce
> a new hypercall that instead of a virtual address takes a guest
> physical address. Will you be OK with this Andrii?
It might work better for this. And introducing a new interface is a chance to 
get rid of a mixed legacy.

> Note that the Linux kernel would also need to be modified to make use
> of this new hypercall, but that's likely close to a 1 line change.I would not 
> say it is a 1 line change.
I think about a page alignment for the runstate area, I'd like to have it 
directly accessed from XEN. I do not like `update_runstate_area()` with its all 
kind of copy_to_guest, done twice a context switch.

[1] https://lists.xenproject.org/archives/html/xen-devel/2019-02/msg00164.html

--
Sincerely,
Andrii Anisov.

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