From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Xen HVM regression on certain Intel CPUs Date: Thu, 28 Mar 2013 17:39:10 +0100 Message-ID: <5154722E.7080605@canonical.com> References: <51530F9F.10805@canonical.com> <515315EC.4030803@canonical.com> <20130327160427.GB6688@phenom.dumpdata.com> <5153222B.3030605@canonical.com> <515323D4.2030806@zytor.com> <5153299A.7070108@canonical.com> <51532B2F.60506@zytor.com> <515454E002000078000C947C@nat28.tlf.novell.com> <51545B7C.4060106@canonical.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6006223952492125995==" Return-path: In-Reply-To: <51545B7C.4060106@canonical.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , wei.y.yang@intel.com, haitao.shan@intel.com, xin.li@intel.com, "H. Peter Anvin" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============6006223952492125995== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig905EBCB27E1AA443C845EC16" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig905EBCB27E1AA443C845EC16 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 28.03.2013 16:02, Stefan Bader wrote: > On 28.03.2013 14:34, Jan Beulich wrote: >>>>> On 27.03.13 at 18:23, "H. Peter Anvin" wrote: >>> On 03/27/2013 10:17 AM, Stefan Bader wrote: >>>>> What does x86info and /proc/cpuinfo show in HVM? >>>> >>>> x86info cpuid[7].ebx =3D 0xbbb and /proc/cpuinfo also shows smep >>>> set. >>> >>> On all CPUs? >>> >>>>> The inbound %cr4 shouldn't matter at all, we try to not rely on >>>>> it. >>>>> >>>>> If the hypervisor presents SMEP to the guest then the guest is >>>>> pretty obviously going to try to use it. >>>> >>>> To me it looks like when bootstrapping the APs things are not yet >>>> ready to use it. If I did not miss something, the only place that >>>> the saved contents of cr4 are used is in startup_32 when the cpus >>>> are brought up. And then just stop dead. Would need to read more >>>> code but a bit weird why the BP is not affected. >>> >>> This feels like a bug in Xen, but I don't know for sure yet. Either >>> which way, it is odd. That write to cr4 should be entirely legitimat= e. >> >> And I would guess one that got fixed already. >> >> Stefan, please try 4.2.2-rc1, or (separately) >> http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommitdiff;h=3D485f3742= 30d39e153d7b9786e3d0336bd52ee661 >> (which I think requires the immediately preceding >> http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommitdiff;h=3D1e6275a9= 5d3e35a72939b588f422bb761ba82f6b >> too). >=20 > The backing explanation does make a lot of sense in reasoning what is g= oing > wrong. Unfortunately the two patches above on their own do not fix the = problem > (I will try to make another go with 4.2.2-rc1). The whole of 4.2.2-rc1 has the same (smep still present in trampoline_cr4_features) outcome. >=20 > For a bit more info I am running a kernel inside the HVM guest which sh= ows the > contents of the cr4 shadow used in the trampoline. Out of interest I co= mpared > those values to the ones used on a bare metal boot and both are identic= al > (0x1407F0). >=20 > That somehow gives some explanation for the patch above failing. Lookin= g at the > code for cr4 updates in vmx_update_guest_cr() a few lines above the new= SMEP > handling, there already was code which would clear the PAE flag when > paging_mode_hap(v->domain) was true. And that would need to be true if = the SMEP > flag should get cleared. And the PAE flag was (and has to be) set befor= e. >=20 > Will be looking into this further. Going back to gather more info and to find some fix. -Stefan --------------enig905EBCB27E1AA443C845EC16 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCgAGBQJRVHIuAAoJEOhnXe7L7s6j1hIP/RqZITS5yAGZFxx11CQLi/yH of1xpzijo/7kb485Z5LPHnVYzR2VkKMUoOqmL6skIKpYIMOHrFScTbDeKrNS2vRs H1j5ogFtR6OwvbZVod+3yN1b5pCepJNirM/WzncHb1R3kVMQxoMj6f7v1RpT8I84 QFEIPnlWTHtxkuMO637q4oXrKHv6IkvvuoWJaz3fsf/Tjton+IWup1fsvCjZ538H 6wuI4BOQJKqStDucvDqaH/XPUqY6xhjbIFz3aHYGaZBX/gc+5YrqILvIdxZvDojD IEItAXaWPmvK+MnYC1fEEOkh2vtP0dk92kd54NYjgNw8+pjQAMr4qRpMX7SoN7XL brUhvh+EX8xm++engWbslW+Hi2jrlps2LI+fIgoM8LhQYFsmbXk62eweoMldzxlV ICW+Y/nRf+z7zd5JqmGQKEnmqlibK8bKrRtxf4m9BhP9Axxto9hl33IwOQAHukyi SlIPtlbDz+0YG9bVqzTDBtc3TCNqhDycq0L5sdTvPtQIMRZulyDSjrWdbx2XUrBy Vdd9hWHKX/SqOXJ3H8tR9eW5H7aoRG7092SWYy/BGr3Cu5cRWhiB1ZVuLc/e9vzC F31bUX6nl1YTpycOuebm3Q9FD20Ku05Hc93XXk9Z9ZEijzuRMe8tW5snmpkrsGdp 1uXhkL0PfmepPRj5WNuq =Z5cR -----END PGP SIGNATURE----- --------------enig905EBCB27E1AA443C845EC16-- --===============6006223952492125995== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6006223952492125995==--