RE: [Xen-devel] EFER in HVM guests

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Li, Xin B
> Sent: 18 December 2006 15:11
> To: Woller, Thomas; Keir Fraser; Nakajima, Jun; Jan Beulich; 
> xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] EFER in HVM guests
> 
> >Xin, when you have a tested hvm/vmx functional patch, we can 
> >run thru SVM platforms for testing and determine if any AMD 
> >specific modifications are needed. Just post to the list the 
> >patch/changeset tested, (CC me directly if you remember). I'll 
> >have our test group run thru the boot tests first, then our 
> >usual ltp/cerberus and windows testing over a few days. 
> >Cheers,
> >  -- Tom
> 
> Hi Tom, the patch is attached, and I've tested it on my side, 
> pls test your side.
> One thing strange to me, why your leaf 0x80000001 needs to 
> handle PAE and APIC feature bits, seems it's same as 
> 0x00000001, is this intended?
> thanks
> -Xin

Xin, 

Good job - thanks for the patch. 

A few notes:

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... ;-)

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. 

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

--
Mats


> 
> >
> >> -----Original Message-----
> >> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> >> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> >> Keir Fraser
> >> Sent: Wednesday, December 13, 2006 8:37 AM
> >> To: Li, Xin B; Keir Fraser; Nakajima, Jun; Jan Beulich; 
> >> xen-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: Re: [Xen-devel] EFER in HVM guests
> >> 
> >> Not quite what I had in mind. Control starts from VMX/SVM so 
> >> we shouldn't need an extra hvm_ops hook function.
> >> 
> >> What I envisage is something like:
> >> 
> >> Vmx_cpuid() {
> >>    /* CPU-specific pre-processing goes here. */
> >>    hvm_cpuid();
> >>    /* CPU-specific post-processing goes here. */ }
> >>  
> >> So VMX/SVM calls out to HVM, not vice versa. You can see that 
> >> this also gives you full flexibility to do pre-processing 
> >> (before calling hvm-generic
> >> function) as well as post-processing.
> >> 
> >> As Jan points out, there's little point in doing this without 
> >> actually pulling out some common code at the same time. Or 
> >> hvm_cpuid() will be a no-op. :-)
> >> 
> >>  -- Keir
> >>    
> >> 
> >> 
> >> On 13/12/06 12:48, "Li, Xin B" <xin.b.li@xxxxxxxxx> wrote:
> >> 
> >> > Is this the framework what you want?
> >> > And we still need merge the common cases here.
> >> > -Xin
> >> > 
> >> >> -----Original Message-----
> >> >> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >> >> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On 
> Behalf Of Keir 
> >> >> Fraser
> >> >> Sent: 2006年11月30日 1:22
> >> >> To: Nakajima, Jun; Jan Beulich; 
> >> xen-devel@xxxxxxxxxxxxxxxxxxx; Keir 
> >> >> Fraser
> >> >> Subject: Re: [Xen-devel] EFER in HVM guests
> >> >> 
> >> >> 
> >> >> *Please* can you make the handling of generic CPUID leaves and 
> >> >> architectural MSRs common HVM code? There is lots of 
> >needless code 
> >> >> duplication right now with niggling differences that 
> shouldn't be 
> >> >> necessary.
> >> >> 
> >> >> -- Keir
> >> >> 
> >> >> On 29/11/06 16:34, "Nakajima, Jun" 
> <jun.nakajima@xxxxxxxxx> wrote:
> >> >> 
> >> >>>> I think it does - allowing a guest to enable EFER.LME 
> when the 
> >> >>>> hypervisor is a 32-bit one is clearly a security 
> >> problem: While I 
> >> >>>> haven't tried it, I would suspect the moment you load 
> a context 
> >> >>>> with such an EFER the whole system's dead.
> >> >>>> Not being able to access EFER is also a potential 
> problem, as a 
> >> >>>> guest should be allowed to set EFER.NX (at least) - the CPUID 
> >> >>>> handling code specifically does not suppress this bit if 
> >> the guest 
> >> >>>> is allowed to use PAE (which we agreed a few days ago 
> >> should be the 
> >> >>>> default anyway).
> >> >>>> 
> >> >>>> Jan
> >> >>>> 
> >> >>> 
> >> >>> I agree that we should allow 32-bit guests to set EFER.NX 
> >> on the PAE 
> >> >>> Xen. We'll fix it. EFER.SCE should not be set on IA-32.
> >> >> 
> >> >> 
> >> >> _______________________________________________
> >> >> 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
> >> 
> >> 
> >> _______________________________________________
> >> 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