Re: [Xen-devel] [PATCH 5/6] x86emul: support INVPCID

[Jan Beulich <jbeulich@suse.com>]

On 27.08.2019 19:27, Andrew Cooper wrote:
> On 27/08/2019 16:53, Jan Beulich wrote:
>> On 27.08.2019 17:31, Andrew Cooper wrote:
>>> On 01/07/2019 12:57, Jan Beulich wrote:
>>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>>> @@ -9124,6 +9126,48 @@ x86_emulate(
>>>>             ASSERT(!state->simd_size);
>>>>             break;
>>>>     +    case X86EMUL_OPC_66(0x0f38, 0x82): /* invpcid reg,m128 */
>>>> +        vcpu_must_have(invpcid);
>>>> +        generate_exception_if(ea.type != OP_MEM, EXC_UD);
>>>> +        generate_exception_if(!mode_ring0(), EXC_GP, 0);
>>>> +
>>>> +        if ( (rc = ops->read(ea.mem.seg, ea.mem.off, mmvalp, 16,
>>>> +                             ctxt)) != X86EMUL_OKAY )
>>>> +            goto done;
>>>
>>> The actual behaviour in hardware is to not even read the memory operand
>>> if it is unused.  You can demonstrate this by doing an ALL_INC_GLOBAL
>>> flush with a non-canonical memory operand.
>>
>> Oh, that's sort of unexpected.
> 
> It makes sense as an optimisation.  There is no point fetching a memory
> operand if you're not going to use it.
> 
> Furthermore, it almost certainly reduces the microcode complexity.

Probably. For comparison I had been thinking of 0-bit shifts instead,
which do read their memory operands. Even SHLD/SHRD, which at least
with shift count in %cl look to be uniformly microcoded, access their
memory operand in this case.

>>>    In particular, I was
>>> intending to use this behaviour to speed up handling of INV{EPT,VPID}
>>> which trap unconditionally.
>>
>> Which would require the observed behavior to also be the SDM
>> mandated one, wouldn't it?
> 
> If you recall, we discussed this with Jun in Budapest.  His opinion was
> no instructions go out of their way to check properties which don't
> matter - it is just that it is far more obvious with instructions like
> these where the complexity is much greater.
> 
> No production systems are going to rely on getting faults, because
> taking a fault doesn't produce useful work.

Maybe I misunderstood your earlier reply then: I read it to mean you
want to leverage INVPCID not faulting on "bad" memory operands for
flush types not using the memory operand. But perhaps you merely
meant you want to leverage the insn not _accessing_ its memory
operand in this case?

Jan

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