From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tim Deegan <tim@xen.org>
Subject: Re: [RFC PATCH 10/16]: PVH xen: introduce vmx_pvh.c
Date: Wed, 20 Feb 2013 09:58:28 +0000
Message-ID: <20130220095828.GA12083@ocelot.phlegethon.org>
References: <20130111180110.55ce77aa@mantra.us.oracle.com>
	<20130124163122.GJ20551@ocelot.phlegethon.org>
	<20130219160534.062dba2f@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <20130219160534.062dba2f@mantra.us.oracle.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

At 16:05 -0800 on 19 Feb (1361289934), Mukesh Rathor wrote:
> On Thu, 24 Jan 2013 16:31:22 +0000
> Tim Deegan <tim@xen.org> 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?

Tim.