WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] EFER in HVM guests

To: "Petersson, Mats" <Mats.Petersson@xxxxxxx>, "Woller, Thomas" <thomas.woller@xxxxxxx>, "Keir Fraser" <keir@xxxxxxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, "Jan Beulich" <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] EFER in HVM guests
From: "Li, Xin B" <xin.b.li@xxxxxxxxx>
Date: Tue, 19 Dec 2006 14:44:33 +0800
Delivery-date: Mon, 18 Dec 2006 22:44:35 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AccTv6r97XujPIxiQ5aNfYfQKg41qAAEUxeAAAJ45NkCtmyz4AAD6ZnBAGdepCAAkrUBoAAC2DfgAB80i2A=
Thread-topic: [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

Attachment: hvm_cpuid.patch
Description: hvm_cpuid.patch

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