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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan



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