Re: [Xen-devel] [PATCH v2] x86: invpcid support

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.03.18 at 18:01, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 02/03/18 16:47, Jan Beulich wrote:
>>>>> On 02.03.18 at 17:23, <wei.liu2@xxxxxxxxxx> wrote:
>>> +static inline void invpcid(unsigned int pcid, unsigned long addr,
>>> +                           unsigned int type)
>>> +{
>>> +    struct {
>>> +        uint64_t pcid:12;
>>> +        uint64_t reserved:52;
>>> +        uint64_t addr;
>>> +    } desc = { .pcid = pcid, .addr = addr };
>>> +
>>> +    asm volatile (
>>> +#ifdef HAVE_AS_INVPCID
>>> +                  "invpcid %[desc], %q[type]"
>>> +                  : /* No output */
>>> +                  : [desc] "m" (desc), [type] "r" (type)
>>> +#else
>>> +                  INVPCID_OPCODE MODRM_ECX_01
>>> +                  : /* No output */
>>> +                  : "a" (type), "c" (&desc)
>>> +#endif
>>> +                  : "memory" );
>> I can see why you need the memory clobber in the #else case
>> (albeit even there it could be avoided by also properly specifying
>> the input), but what is this good for in the #if case?
> 
> This is a tlb flush operation.  I don't think anything good will come
> from having other operations reordered around it.

Well, the question is whose TLB it is that is being flushed. If we
invalidate Xen mappings this way, then yes. But there may be
cases down the road where the construct is used to only flush
guest mappings, in which case the barrier seems pointless. But
anyway - not a big deal for now. It's just that I recall that we
had (or perhaps still have) quite a few too many such barriers.

Jan


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