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: "Woller, Thomas" <thomas.woller@xxxxxxx>, "Li, Xin B" <xin.b.li@xxxxxxxxx>, "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: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Wed, 20 Dec 2006 12:29:27 +0100
Delivery-date: Wed, 20 Dec 2006 03:32:42 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <683860AD674C7348A0BF0DE3918482F603E25E47@xxxxxxxxxxxxxxxxx>
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: AccTv6r97XujPIxiQ5aNfYfQKg41qAAEUxeAAAJ45NkCtmyz4AAD6ZnBAGdepCAAkrUBoAAC2DfgAB80i2AAES+3gAAJBQJAACMaNsA=
Thread-topic: [Xen-devel] EFER in HVM guests
I haven'd done any testing - I had a quick look at the patch in source
form, and wrote my comments based on that. 

If Tom's tests don't show up any problems, I'm happy with the latests
patch-set. 

--
Mats 

> -----Original Message-----
> From: Woller, Thomas 
> Sent: 19 December 2006 20:38
> To: Li, Xin B; Petersson, Mats; Keir Fraser; Nakajima, Jun; 
> Jan Beulich; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] EFER in HVM guests
> 
> Mats, which configurations did you test?  Can you post those results?
> 
> Xin, 
> Attached is overnight testing on patch you sent for 32bit hv 
> (xls spreadsheet) on top of 13078, so far looks ok, we have 
> planned to do some 32bit PAE and 64bit hv with HVM AMD-V 
> guest testing.  With the interaction/comments from Mats, do 
> you anticipate another patch with more consolidation of SVM/VMX code?
> 
> Thanks
> Tom 
> 
> 
> 
> > -----Original Message-----
> > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> > [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Li, Xin B
> > Sent: Tuesday, December 19, 2006 8:25 AM
> > To: Li, Xin B; Petersson, Mats; Woller, Thomas; Keir Fraser; 
> > Nakajima, Jun; Jan Beulich; xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-devel] EFER in HVM guests
> > 
> > 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
> > 
> > 
> > 
> 



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

<Prev in Thread] Current Thread [Next in Thread>