From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: xsave=0 workaround needed on 3.2 kernels with Xen 4.1 or Xen-unstable. Date: Tue, 8 May 2012 20:35:11 -0400 Message-ID: <20120509003510.GA19643@phenom.dumpdata.com> References: <20120430193713.GA12817@phenom.dumpdata.com> <4FA113B902000078000810C3@nat28.tlf.novell.com> <4FA268CD02000078000814E4@nat28.tlf.novell.com> <4FA792C00200007800081F06@nat28.tlf.novell.com> <20120508000813.GA29587@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: AP Cc: Jeremy Fitzhardinge , Tim.Deegan@citrix.com, weidong.han@intel.com, stefan.bader@canonical.com, xen-devel , Jan Beulich List-Id: xen-devel@lists.xenproject.org On Mon, May 07, 2012 at 05:41:28PM -0700, AP wrote: > On Mon, May 7, 2012 at 5:08 PM, Konrad Rzeszutek Wilk < > konrad.wilk@oracle.com> wrote: > > > > > > No, this is specifically the wrong thing. From what we know so far > > > > (i.e. the outcome of the above printing you added) the problem in > > > > in the Dom0 kernel (in it never setting CR4.OSXSAVE prior to > > > > attempting XSETBV). What your patch efectively does is take away > > > > control from the guest kernels to control the (virtual) CR4 flag... > > > > > > > > > That allowed the system to boot successfully though I did see the > > > > > following message: > > > > > (XEN) domain.c:698:d0 Attempt to change CR4 flags 00042660 -> > > > > > 00002660 > > > > > > > > ... which is what this message is telling you. > > > > > > > > > Not sure if the above patch is right fix but I hope it was at least > > > > > helpful in pointing at where the problem might be. > > > > > > > > > > BTW, I see the same invalid op issue with Xen 4.1.2 if I boot with > > > > > xsave=1. > > > > > > > > Sure, as it's a kernel problem. It's the kernel that needs logging > > > > added, > > > > to find out why the CR4 write supposedly happening immediately > > > > prior to the XSETBV (set_in_cr4(X86_CR4_OSXSAVE)) doesn't actually > > > > happen, or doesn't set the flag. Perhaps something fishy going on > > > > > > xen_write_cr4 explicitly turns off X86_CR4_OSXSAVE. > > > > Where did you see that code? Looking at the Linus's tree this is what I > > see > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/x86/xen/enlighten.c;h=a8f8844b8d32690b8a189bc37d12cd3f286a81cd;hb=HEAD > > > > So who added that code? I am not seeing it in v3.0 either? > > This is in the Ubuntu 11.10 kernel: > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=arch/x86/xen/enlighten.c;h=ce01f6d63507fd44288989ca0ba81a0f5bf04e3f;hb=HEAD#l812 > > After some digging around, it looks like this is an Ubuntu 11.10 only patch: > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commitdiff;h=3f3fba59aa5773836d94799d10b692f9b7ea16a0;hp=5e498fdb19f5b27699f063eb10040612b824160b Ugh. There are looks to be a bug in Fedora as well: https://bugzilla.redhat.com/show_bug.cgi?id=801650 for this.