[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.c



On Thu, 21 Feb 2013 09:10:01 +0000
Tim Deegan <tim@xxxxxxx> wrote:

> At 19:05 -0800 on 20 Feb (1361387119), Mukesh Rathor wrote:
> > On Wed, 20 Feb 2013 09:58:28 +0000
> > Tim Deegan <tim@xxxxxxx> wrote:
> > 
> > > At 16:05 -0800 on 19 Feb (1361289934), Mukesh Rathor wrote:
> > > > On Thu, 24 Jan 2013 16:31:22 +0000
> > > > Tim Deegan <tim@xxxxxxx> wrote:
> > > > 
> > > > > At 18:01 -0800 on 11 Jan (1357927270), Mukesh Rathor wrote:
> > > > > > +
> > > > > > +        case EXIT_REASON_CPUID:              /* 10 */
> > > > > > +        {
> > > > > > +            if ( guest_kernel_mode(vp, regs) ) {
> > > > > > +                pv_cpuid(regs);
> > > > > > +
> > > > > > +                /* Because we are setting CR4.OSFXSR to 0,
> > > > > > we need to disable
> > > > > > +                 * this because, during boot, user process
> > > > > > "init" (which doesn't
> > > > > > +                 * do cpuid), will do 'pxor xmm0,xmm0' and
> > > > > > cause #UD. For now 
> > > > > > +                 * disable this. HVM doesn't allow setting
> > > > > > of CR4.OSFXSR.
> > > > > > +                 * fixme: this and also look at
> > > > > > CR4.OSXSAVE */ +
> > > > > > +                __clear_bit(X86_FEATURE_FXSR, &regs->edx);
> > > > > 
> > > > > Shouldn't this be gated on which leaf the guest asked for?
> > > > 
> > > > Yup, looking at it. X86_FEATURE_FXSR is EAX==1, but it doesn't
> > > > work. The user process "init" running nash is executing pxor
> > > > %xmm0, %xmm0 and taking #UD. Strangely, it works with EAX==0,
> > > > meaning if I clear the bit for EAX==0, changing the intel
> > > > string "ineI".  This user process doesn't do cpuid, so it must
> > > > be affected by it some other way.
> > > > 
> > > > Pretty hard to debug since it's in nash user code from ramdisk
> > > > and I am not able to set breakpoint or put printf's easily to
> > > > figure why clearing bit for EAX==0 makes it work, or what's
> > > > going on for PV and HVM guest. CR0.EM is 0, so UD is coming
> > > > from CR4.OSFXSR==0. Reading the SDMs to learn OSFXSR stuff
> > > > better....
> > > 
> > > Perhaps you need to clear the FXSR feature bit in leaf
> > > 0x80000001:EDX as well?
> > 
> > That appears to be AMD only.
> 
> It still needs to be handled. :)   You are testing this stuff on AMD
> as well, right?

Right, in pvh_svm.c when its ported. I had talked to someone from AMD
at xen summit who said he'd port it to AMD as soon as phase I patch
is checked in. It shouldn't be too hard to do that. I estimate a week
or two if I was to do SVM changes. 

Right now my hurdle working on Version 2 of the patch is all this SSE
stuff that I'm trying to figure out. I was hoping to punt it to phase
II by turning off whatever bits in CPUID, but nothing works. 

Thanks,
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.