From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: __unlazy_fpu with Sandy Bridge? Date: Thu, 28 Apr 2011 07:45:04 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Haitao Shan Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org See xen-unstable:23248. I plumbed a call to xc_cpuid_config_xsave() into xc_cpuid_pv_policy() in libxc/xc_cpuid_x86.c. Without this a recent Linux kernel fails even more quickly, as it detects XSAVE but then finds the feature leaves all zeroes, and panics. Best guess is that filling in the leaves using exactly the same method as for HVM guests (which is what xc_cpuid_config_xsave() was originally writte= n for) is wrong for some reason. -- Keir On 28/04/2011 02:19, "Haitao Shan" wrote: > I will have a look. But Keir, could you please share some context? > Any changes made to Xsave/CPUID so far? > =A0 > Shan Haitao > 2011/4/27 Keir Fraser >> On 27/04/2011 03:58, "Konrad Rzeszutek Wilk" wr= ote: >>=20 >>> On Tue, Apr 26, 2011 at 09:57:58PM -0400, Konrad Rzeszutek Wilk wrote: >>>> I bought over the weekend a Sandy Bridge machine and quite often >>>> when I launch a guest I get this: >>>=20 >>> Which disappear if I do 'xsave=3D0'. Looks like there is still some linge= ring >>> bug? >>> (I did build it with the patch that Keir posted). >>=20 >> I may have plumbed the XSAVE CPUID stuff incorrecty for PV guests. Intel >> probably need to take a look. >>=20 >> =A0-- Keir >>=20 >>>>=20 >>>> [ =A0 =A01.519320] modprobe used greatest stack depth: 6348 bytes left >>>> [ =A0 =A01.528966] udevd (1158): /proc/1158/oom_adj is deprecated, please = use >>>> /proc/1158/oom_score_adj instead. >>>>=20 >>>> [ =A0 =A01.610819] BUG: unable to handle kernel paging request at cb5b007f >>>> [ =A0 =A01.610839] IP: [] __unlazy_fpu+0x20/0x84 >>>> [ =A0 =A01.610854] *pdpt =3D 000000000b49f027 *pde =3D 000000000c0b1067 *pte =3D >>>> 800000000b5b0061 >>>> [ =A0 =A01.610874] Oops: 0003 [#1] SMP >>>> [ =A0 =A01.610886] last sysfs file: /sys/devices/virtual/tty/ptyp9/uevent >>>> [ =A0 =A01.610896] Modules linked in: xen_blkfront xen_netfront xen_fbfron= t >>>> fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs >>>> [ =A0 =A01.610934] >>>> [ =A0 =A01.610941] Pid: 1424, comm: ifup Not tainted >>>> 2.6.39-rc4yes_xen_blkdev-00489-gfa5424e #1 >>>> [ =A0 =A01.610959] EIP: 0061:[] EFLAGS: 00010086 CPU: 1 >>>> [ =A0 =A01.610969] EIP is at __unlazy_fpu+0x20/0x84 >>>> [ =A0 =A01.610977] EAX: ffffffff EBX: ead8c4e0 ECX: cb602700 EDX: ffffffff >>>> [ =A0 =A01.610987] ESI: eb3d3180 EDI: cb5afd40 EBP: cb60de60 ESP: cb60de5c >>>> [ =A0 =A01.610997] =A0DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 >>>> [ =A0 =A01.611007] Process ifup (pid: 1424, ti=3Dcb60c000 task=3Dcb602700 >>>> task.ti=3Dcb5c8000) >>>> [ =A0 =A01.611017] Stack: >>>> [ =A0 =A01.611023] =A0cb602700 cb60de88 c102b938 ead8c4e0 eb3d5480 0060224c >>>> 00000001 eb3d5480 >>>> [ =A0 =A01.611055] =A0cb4adc00 eb3d5480 ead8c4e0 cb5c9f50 c13d45ce cb60df1c >>>> 00000282 5fb55ce4 >>>> [ =A0 =A01.611055] =A000000000 c15e7480 ead8c4e0 c15e7480 c15e7480 ead8c758 >>>> cb60df1c c15e7480 >>>> [ =A0 =A01.611055] Call Trace: >>>> [ =A0 =A01.611055] =A0[] __switch_to+0x40/0xfa >>>> [ =A0 =A01.611055] =A0[] schedule+0x5fb/0x667 >>>> [ =A0 =A01.611055] =A0[] ? xen_restore_fl_direct_reloc+0x4/0x4 >>>> [ =A0 =A01.611055] =A0[] ? free_hot_cold_page+0xf8/0x100 >>>> [ =A0 =A01.611055] =A0[] ? get_phys_to_machine+0x18/0x4c >>>> [ =A0 =A01.611055] =A0[] ? xen_force_evtchn_callback+0xf/0x14 >>>> [ =A0 =A01.611055] =A0[] ? check_events+0x8/0xc >>>> [ =A0 =A01.611055] =A0[] ? xen_restore_fl_direct_reloc+0x4/0x4 >>>> [ =A0 =A01.611055] =A0[] ? _raw_spin_unlock_irqrestore+0x14/0x17 >>>> [ =A0 =A01.611055] =A0[] ? add_wait_queue+0x30/0x35 >>>> [ =A0 =A01.611055] =A0[] ? do_wait+0x183/0x1e1 >>>> [ =A0 =A01.611055] =A0[] ? sys_wait4+0x88/0xa1 >>>> [ =A0 =A01.611055] =A0[] ? wait_noreap_copyout+0xdf/0xdf >>>> [ =A0 =A01.611055] =A0[] ? sys_waitpid+0x13/0x15 >>>> [ =A0 =A01.611055] =A0[] ? sysenter_do_call+0x12/0x28 >>>> [ =A0 =A01.611055] Code: 31 ff 5a 89 f8 59 5b 5e 5f 5d c3 55 89 c1 89 e5 5= 7 8b >>>> 40 >>>> 04 f6 40 0c 01 74 6b b0 01 84 c0 74 1f 83 c8 ff 8b b9 38 03 00 00 89 c= 2 >>>> <0f> >>>> ae 37 8b 81 38 03 00 00 f6 80 00 02 00 00 01 75 18 eb 2e b0 >>>> [ =A0 =A01.611055] EIP: [] __unlazy_fpu+0x20/0x84 SS:ESP >>>> 0069:cb60de5c >>>> [ =A0 =A01.611055] CR2: 00000000cb5b007f >>>> [ =A0 =A01.611055] ---[ end trace 0e00f93ab96a1012 ]--- >>>> [ =A0 =A01.611055] Fixing recursive fault but reboot is needed! >>>>=20 >>>>=20 >>>> Has anybody seen something similar to this? >>>>=20 >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xensource.com >>>> http://lists.xensource.com/xen-devel >>>=20 >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >>=20 >>=20 >>=20 >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >=20 >=20