RE: [Xen-devel] EFER in HVM guests

["Li, Xin B" <xin.b.li@xxxxxxxxx>]

Mats, Did you find any issue on your side?

-Xin 

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Li, Xin B
>Sent: Tuesday, December 19, 2006 2:45 PM
>To: Petersson, Mats; Woller, Thomas; Keir Fraser; Nakajima, 
>Jun; Jan Beulich; xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [Xen-devel] EFER in HVM guests
>
>>
>>The 0x80000001 leaf was originally an "AMD only" leaf for 
>>adding new "non-Intel compatible" features, such as 3DNow! and 
>>long-mode, but since x86_64 was adopted by Intel, it's 
>>available on Intel processors too. It should be done the same 
>>on both AMD and Intel, and since 0x80000001 contains another 
>>copy of the APIC and PAE bits, they should be masked for both 
>>processors on both 1 and 0x80000001. [Of course, I doubt that 
>>anyone would "prefer" to use 0x80000001 from using 1 as the 
>>index for the leaf unless the coder is already reading 
>>0x800000001 for some other reason - to detect LM for example]. 
>>
>>I would like to see the handling of 0x80000001 in the common 
>>case cover PAE/PSE36/APIC features, as that's nor 
>>arch-specific. The fact that no-one actually uses it currently 
>>isn't a good argument for not getting it right at this time 
>>rather than fixing hard-to-find bugs later on... ;-)
>>
>
>Mats,
>Leaf 0x80000001 on Intel processors only uses 4 bits in ECX and EDX,
>they are:
>LAHF/SAHF:                     bit 0 of ECX
>SYSCALL/SYSRET:                bit 11 of EDX
>Execution Disable bit: bit 20 of EDX
>LM bit:                        bit 29 of EDX
>All other bits are reserved to 0.
>
>
>>Clearing MWAIT bit should also be made common - I doubt anyone 
>>will notice the single instruction saved by combining it with 
>>a bunch of other bits, compared to the overall benefit of 
>>trivially seeing that it's dealt with the same way on both 
>>architectures. 
>
>I did have this in mind when creating this patch, but I'm not sure if
>MWAIT virtualization is common on both sides, so just keep it 
>there, and
>The patch attached has this fixed.
>
>>
>>Just out of curiosity, why did you change the parameters 
>>passed to svm_do_cpuid - I can see why you wouldn't need to 
>>pass regs->eax when it's available in regs, but digging out 
>>the vmcb again can't be better than passing the already 
>>existing one? [Don't worry about it, I'm just curious about 
>>why the change was made]. 
>
>In my mind, just pass parameters you don't have in hand. And yes,
>actually vmcb should be a parameter here :-)
>
>-Xin
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel