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

Re: [Xen-devel] Ping: [PATCH] x86: improve vCPU selection in pagetable_dying()

>>> On 03.10.18 at 18:56, <george.dunlap@xxxxxxxxxx> wrote:
> On 09/26/2018 08:04 AM, Jan Beulich wrote:
>>>>> On 25.09.18 at 18:22, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 18/09/18 13:44, Jan Beulich wrote:
>>>>>>> On 10.09.18 at 16:02, <JBeulich@xxxxxxxx> wrote:
>>>>> Rather than unconditionally using vCPU 0, use the current vCPU if the
>>>>> subject domain is the current one.
>>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> What improvement is this intended to bring?
>> I've come across this quite a while ago when investigating possibly
>> dangerous uses of d->vcpu[], well before your series to improve the
>> situation there. I generally consider it wrong to hard code use of
>> d->vcpu[0] whenever it can be avoided.
>>> Shadows are per-domain, and the gmfn in question is passed in by the
>>> caller.  AFACIT, it is a logical bug that that the callback takes a vcpu
>>> rather than a domain in the first place.
>> Did you look at the 3-level variant of sh_pagetable_dying()? It very
>> clearly reads the given vCPU's CR3.
> Yes; and so the current implementation which unconditionally passes vcpu
> 0 is clearly a bug.
>> Looking at things again (in particular
>> the comment ahead of pagetable_dying()) I now actually wonder why
>> HVMOP_pagetable_dying is permitted to be called by other than a domain
>> for itself. There's no use of it in the tool stack. Disallowing the unused
>> case would mean the fast-path logic in sh_pagetable_dying() could
>> become the only valid/implemented case. Tim?
> Not so -- a guest could still call pagetable_dying() on the top level PT
> of a process not currently running.

Oh, you're right of course.

> I would be totally in favor of limiting this call to the guest itself,
> however -- that would simplify the logic even more.

Will do in v2 then.


Xen-devel mailing list



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