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.
>
>> 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.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
