[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [ARM] gvirt_to_maddr fails when DomU is created
Hi Juergen,
I have noticed on the last few threads that your e-mails don't get threaded
correctly. Looking at the source, I can't find the In-Reply-To tag. Do you have
any issue with your e-mail?
On 29/11/2018 09:51, Juergen Gross wrote:
On 29/11/2018 10:39, Jan Beulich wrote:
On 28.11.18 at 01:05, <andrew.cooper3@xxxxxxxxxx> wrote:
update_runstate_area() using a virtual address is a complete misfeature,
and the sooner we can replace it, the better. It's history is with x86
PV guests, where the early ABIs were designed in terms of Linux's
copy_{to,from}_user().
It is similarly broken in x86 with meltdown mitigations, as well as SMAP
considerations (PAN in ARM, iirc).
We've got two options. Invent a new API which takes a gfn/gaddr, or
retrofit the API to be "you pass a virtual address, we translate to
gfn/gaddr, then update that". Perhaps both.
When this was last discussed, I think the "onetime translate to
gfn/gaddr" was a good enough compatibility to cope with existing guests,
but that we should have a more clean way for modern guests.
I don't think a one-time translate can be a replacement without
the guest giving its consent, at which point the guest could as
well be switched to whatever the replacement interface is going
to be. Aiui (the introduction of the functionality predating my
involvement with Xen) the original idea was that guests would
specifically be allowed to context switch the mapping of the
involved linear address.
Furthermore for x86-64 guests we already have logic to deal
with the case where there is no present mapping at the time
the write is to occur, as that's a common situation with x86-64
guest user mode running with kernel page tables removed.
For x86-32 guests with Meltdown mitigation in place something
similar might indeed be needed. Whether something like this is
doable on ARM depends on whether Xen has a way to know
at which point missing mappings re-appear.
In any case we want some interface using gfn/gaddr for performance
reasons: Always having to do a vaddr->gaddr translation is expensive
(especially for HVM/PVH and probably on ARM, too), so we should try to
avoid that.
On Arm, performance is one of the reason, but not the main one. Using Virtual
Address is by default unreliable as you have no way to prevent the guest to play
with its page-tables. For instance, Arm requires to go through an invalid state
when updating the page-tables entry under certain condition (e.g superpage <->
small mapping).
The long-term goal is to use guest physical address for all hypercalls rather
than guest virtual address.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
