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

Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts



On 24/01/18 13:34, Woodhouse, David wrote:
> On Wed, 2018-01-24 at 13:12 +0000, Andrew Cooper wrote:
>> +             * Squash the domid and vcpu id together for comparason
> *comparison
>
>> +             * efficiency.  We could in principle stash and compare the 
>> struct
>> +             * vcpu pointer, but this risks a false alias if a domain has 
>> died
>> +             * and the same 4k page gets reused for a new vcpu.
>> +             */
> Isn't that also true if the domain has died and its domain-id gets re-
> used?

In principle, yes.  However, a toolstack needs to have non-default
behaviour[1] to reuse a domid without wrapping around 32k.

>
>> +            unsigned int next_id = (((unsigned int)nextd->domain_id << 16) |
>> +                                    (uint16_t)next->vcpu_id);
> I am loath to suggest *more* tweakables, but given the IBPB cost is
> there any merit in having a mode which does it only if the *domain* is
> different, regardless of vcpu_id?

This would only be a win if you were regularly cross-scheduling vcpus
from the same domain, which case you've probably other issues to be
worried about.

> If a given domain is running on HT siblings, it ought to be doing its
> own mitigation — setting STIBP for userspace if it wants, ensuring its
> own kernel is safe by having IBRS set or using retpoline, etc.

~Andrew

[1] Is this trying to be a subtle hint?

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

 


Rackspace

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