From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.c Date: Thu, 21 Feb 2013 11:20:04 -0800 Message-ID: <20130221112004.05fdb740@mantra.us.oracle.com> References: <20130111180110.55ce77aa@mantra.us.oracle.com> <20130124163122.GJ20551@ocelot.phlegethon.org> <20130219160534.062dba2f@mantra.us.oracle.com> <20130220095828.GA12083@ocelot.phlegethon.org> <20130220190519.5fb537b1@mantra.us.oracle.com> <20130221091001.GD24051@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130221091001.GD24051@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: "Xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Thu, 21 Feb 2013 09:10:01 +0000 Tim Deegan wrote: > At 19:05 -0800 on 20 Feb (1361387119), Mukesh Rathor wrote: > > On Wed, 20 Feb 2013 09:58:28 +0000 > > Tim Deegan wrote: > > > > > At 16:05 -0800 on 19 Feb (1361289934), Mukesh Rathor wrote: > > > > On Thu, 24 Jan 2013 16:31:22 +0000 > > > > Tim Deegan 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, ®s->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