On 29/11/2018 10:39, Jan Beulich wrote: >>>> On 28.11.18 at 01:05, <[email protected]> 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. Juergen _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
