Re: [ARM] gvirt_to_maddr fails when DomU is created

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	vlad.babchuk@gmail.com, Julien Grall <julien.grall@arm.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [ARM] gvirt_to_maddr fails when DomU is created
Date: Thu, 29 Nov 2018 10:03:50 +0000	[thread overview]
Message-ID: <6de36a91-858d-8a46-fda0-3982588e72ae@citrix.com> (raw)
In-Reply-To: <5BFFB3CD020000780020115A@prv1-mh.provo.novell.com>

On 29/11/2018 09:39, Jan Beulich wrote:
>>>> On 28.11.18 at 01:05, <andrew.cooper3@citrix.com> 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.

That entirely depends on how guests currently use the address they set
up.  The purpose of investigating an option like this is specifically to
avoid needing to alter the guest...

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

... so we can get something which works without having to do a full
pagewalk (and nested vmexit!) on every context switch and each time we
toggle the guest pagetables.

Furthermore, looking at the content held in the runstate area, what do
guests actually use the information for?  It looks like it is of
marginal use for diagnostics within the guest.

~Andrew

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