On 02/04/2025 11:03 am, Jan Beulich wrote:
> On 02.04.2025 11:56, Andrew Cooper wrote:
>> --- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
>> +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
>> @@ -559,25 +559,6 @@ static inline void __vmxoff(void)
>> : : : "memory" );
>> }
>>
>> -static inline int __vmxon(u64 addr)
>> -{
>> - int rc;
>> -
>> - asm volatile (
>> - "1: " VMXON_OPCODE MODRM_EAX_06 "\n"
>> - " setna %b0 ; neg %0\n" /* CF==1 or ZF==1 --> rc = -1 */
>> - "2:\n"
>> - ".section .fixup,\"ax\"\n"
>> - "3: sub $2,%0 ; jmp 2b\n" /* #UD or #GP --> rc = -2 */
>> - ".previous\n"
>> - _ASM_EXTABLE(1b, 3b)
>> - : "=q" (rc)
>> - : "0" (0), "a" (&addr)
>> - : "memory");
> ... the memory barrier here. I will admit I'm not sure I see why it's
> there, but if the removal was deliberate, then a sentence wants saying
> about this in the description.
Hmm. (Honestly, I wrote the asm goto from scratch, rather than copying it).
The VMXON instruction itself will modify the 4k vmxon_region. It's an
opaque region, and it might (implementation specific) become
non-coherent with main memory.
However, we don't have a 4k object we could pass as a faux memory
operand, nor can we use asm goto with outputs (That requires a newer
toolchain, and some compiler errata workarounds, but we can do it
conditionally I think).
Lets put the memory clobber back in.
> With that or with it re-added:
> Reviewed-by: Jan Beulich <jbeul...@suse.com>
Thanks.
~Andrew
