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 16:02:20 +0100 Message-ID: <51545B7C.4060106@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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5997714639528824711==" Return-path: In-Reply-To: <515454E002000078000C947C@nat28.tlf.novell.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) --===============5997714639528824711== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig81C5AC0B470F55A5758FBDC6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig81C5AC0B470F55A5758FBDC6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 legitimate= =2E >=20 > And I would guess one that got fixed already. >=20 > Stefan, please try 4.2.2-rc1, or (separately) > http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommitdiff;h=3D485f37423= 0d39e153d7b9786e3d0336bd52ee661 > (which I think requires the immediately preceding > http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommitdiff;h=3D1e6275a95= d3e35a72939b588f422bb761ba82f6b > too). The backing explanation does make a lot of sense in reasoning what is goi= ng wrong. Unfortunately the two patches above on their own do not fix the pr= oblem (I will try to make another go with 4.2.2-rc1). For a bit more info I am running a kernel inside the HVM guest which show= s the contents of the cr4 shadow used in the trampoline. Out of interest I comp= ared those values to the ones used on a bare metal boot and both are identical= (0x1407F0). That somehow gives some explanation for the patch above failing. Looking = at the code for cr4 updates in vmx_update_guest_cr() a few lines above the new S= MEP 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 th= e SMEP flag should get cleared. And the PAE flag was (and has to be) set before.= Will be looking into this further. -Stefan >=20 > Jan >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >=20 --------------enig81C5AC0B470F55A5758FBDC6 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/ iQIcBAEBCgAGBQJRVFuEAAoJEOhnXe7L7s6jnSUP/0BIovODbyGoG2wtcbW2kTyv 5Y3WKz6m4QwTRV/OOhCNKyXg38Xz3mfpUv4/pI2XrsjqQ81w2/U8mOlff/C2k/gE R5c3SzqdtLEGLkGwXsGWFMhBDJrLQ6j332EXnBdnq9Qa8VuNHYtMjKrU5kVQhF0X aTS2XfwsCEERbiLicCIqbE6mpETyG1+iUExKIDZC3/pL+WOXUw84/mgF/WoCmNOV 0/9kGzE5IfI3shWYYGADdLN0P8GGlk++F5y4zrSHqordaOku8dXmtF9OSbYofXJa wpefZvdoBw8lid5TdobIMQXLyHQf8fw/4nNVR9gpobGui1WnYBIsuTh1/NyRjqoW CEJN/8DN23O9K6nyzS8czzWMlhEz72jxuGjI7rZRk5wZ7f9NrwFDVpCNs9xOSQqb LwnRuv3eZyRlJrsF95e/7sjENeDuXXnwqpDUvdU4/I4UVFvft8pHhBhGz6pyhRQ9 gwdPmKdNjvcPHVq7MkPFD0V09JA8uVC0WmJWGyDPafl6g3driMMGTrXkcgO8556i KN4gxBNYu/5VERRuXf61nQJe6XvlRMZjbutq2X+p9JleeslXaJ/2nsd3ZvQZ36se CVCiDyVT98zuzb8FWHPtwfdLkGFklIkxYcoeIeRFwBu4ZnnQsSNw0xy/6WlYNnE8 8GmC0l0bPgIKgoUeuPoS =UcE7 -----END PGP SIGNATURE----- --------------enig81C5AC0B470F55A5758FBDC6-- --===============5997714639528824711== 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 --===============5997714639528824711==--