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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan



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