[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Sorry for the formatting, using the gmail web-interface.

On Tue, Feb 12, 2019 at 7:23 PM Andrii Anisov <andrii.anisov@xxxxxxxxx> wrote:
> 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.

The Arm Arm requires the modification in the page-table to be atomic.
Otherwise you may face strange behavior as the entry may be use by the
page-table walker at the same time. This is the same in the hypervisor
case, you will either see the old value, a non-existent entry (because
of break-before-make), or the new value.

> 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.

You can't really control what a VM is doing with its page-tables. An
OS may decide to shatter/gather pages in smaller/bigger mapping. This
is actually done by Linux for memory used by userspace. We have some
workaround in the privcmd driver for preventing Linux to play with
buffer passed via hypercall. Although, I suspect this is not enough
given the weird error I see on osstest time to time.

Another issue with the virtual address is in the case of a blind
hypervisor. The OS may decide to hide its page-tables from the
hypervisor and therefore you would not be able to translate a virtual

This is why virtual address should be avoided as much as possible.
IIRC, there was some discussion during Xen Summit 2017 in Budapest
about using guest physical address rather than guest virtual address.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.