Re: [Xen-devel] [ARM] gvirt_to_maddr fails when DomU is created

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan



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