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

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



>>> On 25.08.13 at 00:18, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> I certainly like and encourage of the idea of getting rid of the fixed
> registers due to the hex literals.  However, are macros really the
> correct solution?
> 
> __vmread_safe(field, value) now has non-function like semantics for value.
> 
> To me, the more obvious (and as far as I can tell, functionally
> identical) approach would be for
> 
> unsigned long always_inline __vmread_safe(unsigned long field, unsigned
> long *value)
> 
> The compiler, given the correct constraints for value could resolve the
> pointer back to the caller as it inlined the function, and calls would
> look like "__vmread_safe(field, &value);" which looks rather more natural.

The constraints aren't the problem - the use of sizeof(value) inside
the macro is. You can't pass both pointers to 32-bit and 64-bit data
items into the function, and then have the function guess what the
type is to be.

> As for the memory clobbers, I see no indication from the VMX instruction
> reference that vmread or inv{ept,vpid} have relevant side effects
> requiring a clobber.  For the load functions and vmwrite, there is a
> possibilty of a memory clobber if someone has peaked into the relevant
> VMCS page(s).  However, doing so defeats the purpose of vmread/write, so
> as far as I can tell, we could argue away the clobbers on those grounds
> alone.

Good; I'm still hoping to hear an opinion from Intel engineers too.

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®.