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

Re: [Xen-devel] [PATCH v3 3/4] VMX: use proper instruction mnemonics if assembler supports them



>>> On 26.08.13 at 15:05, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 26/08/2013 11:18, Jan Beulich wrote:
>>  static inline void __vmpclear(u64 addr)
>>  {
>> -    asm volatile ( VMCLEAR_OPCODE
>> -                   MODRM_EAX_06
>> +    asm volatile (
>> +#ifdef HAVE_GAS_VMX
>> +                   "vmclear %0\n"
>> +#else
>> +                   VMCLEAR_OPCODE MODRM_EAX_06
>> +#endif
>>                     /* CF==1 or ZF==1 --> crash (ud2) */
>>                     UNLIKELY_START(be, vmclear)
>>                     "\tud2\n"
>>                     UNLIKELY_END_SECTION
>> +#ifdef HAVE_GAS_VMX
>> +                   : "+m" (addr)
> 
> Why is this "+m" ?  (and specifically different to some of its counterparts)

Apparently I misread "The operand of this instruction is always 64 bits
and is always in memory. If the operand is the current-VMCS
pointer, then that pointer is made invalid (set to
FFFFFFFF_FFFFFFFFH)" to mean that the operand gets overwritten
rather than the CPU-internal pointer.

>> +    asm volatile (
>> +#ifdef HAVE_GAS_VMX
>> +                   "vmread %q2, %1\n\t"
>> +#else
>> +                   VMREAD_OPCODE MODRM_EAX_ECX
>> +#endif
>> +                   /* CF==1 or ZF==1 --> rc = 0 */
>> +                   "setnbe %0"
>> +#ifdef HAVE_GAS_VMX
>> +                   : "=qm" (okay), "=rm" (*value)
>> +                   : "r" (field)
>> +#else
>> +                   : "=qm" (okay), "=c" (*value)
>> +                   : "a" (field)
>> +#endif
> 
> Why the %q2 qualifer with "r" (field).  Would it not be cleaner as %2
> and "q" (field) ?  (And similar lower down)

That q was just a leftover from the macro variant. It's not wrong,
but confusing. I'll remove it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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