RE: [Xen-devel] EFER in HVM guests

["Woller, Thomas" <thomas.woller@xxxxxxx>]

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

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