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:06:37 +0100 Message-ID: <51545C7D.2040608@canonical.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3569975988564552618==" Return-path: 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: Keir Fraser 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) --===============3569975988564552618== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig406149B8588C0BF08A813897" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig406149B8588C0BF08A813897 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 27.03.2013 21:24, Keir Fraser wrote: > On 27/03/2013 16:45, "Stefan Bader" wrote:= >=20 >>>> Seems that I was relying on the wrong source of information when che= cking >>>> SMEP >>>> support. The cpuid command seems at fail. But /proc/cpuinfo reports = it. So >>>> that >>>> at least explains where that comes from... sorry for that. >>> >>> OK, so if you boot Xen with smep=3D1 (which disables SMEP, kind of >>> counterintuive flag) >>> that would work fine? >> >> Rebooting with smep=3D1 as a hv argument does not fix it. But I would = be careful >> since I just quickly did this without checking whether Xen 4.2.1 undes= tands >> the >> flag already. >=20 > Yes, the flag is understood by all Xen 4.2 releases. However it is not > inverted as you believe: it really is smep=3D0 or smep=3Doff or even no= -smep to > disable SMEP. smep=3D1 will enable SMEP (which is the default anyway). >=20 > I also checked how CPUID.SMEP gets set for an HVM guest, and it is very= > obviously masked off if SMEP support has been disabled or is unavailabl= e. So > I do not think we can be erroneously passing the CPUID flag to the gues= t. No you are completely right. The inverse boolean got me for good. So to s= ummarize: - smep=3D0 as hypervisor argument avoids the problem for all guests - nosmep as hvm guest arguement avoids the problem for that guest - /proc/cpuinfo correctly reflects whether smep has been masked off or no= t >=20 > -- Keir >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >=20 --------------enig406149B8588C0BF08A813897 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/ iQIcBAEBCgAGBQJRVFx9AAoJEOhnXe7L7s6jppEP/1luG6vm7L8hAEDPI118CTzy noIljJVfhfzAlLZ5DP96kHfDDkqLqG6eAX6K4nGU+rEwoAMe8uX61D+BjNzMyB2+ 3i3jUKcJhO+tTNfuO5T1qDSHFlcdc0N6XZFdQK5lTmWnFuykTDLT1fp6/hmzTdo7 0rdX0P98QNFSCauCl6YnsdCc9fX19TdOM15rqXXr8EwAw3y3qVPBlKbO+QLw7+nV fIfGtsFKnLHK2gccmg+RRNSv+MoSkN2hSQ1sStLLBVkiBw4Q3sJEHd5NTK+sSrqn eDRrJxuq3Wk6swgFjnpHkJC18FflxAdIyLRQy6G8iiHv+Q0cl07XlLk4cUyZ/mhL YlIP3UqCVNHHiJaCJ8f2xCevl2reaImGBnCMmDLKtLfnyB4XfF3zlUCinfaTMN82 HlJAJ96H1awbTQJkV2DrI9Gf1He5JYkDE2cxyEQWS3EyU5M9MEFe+JHHw/dqlB0z t6p9PeecCzFD6+A3Jis1Dwaa7VnzUl++HhPYFUK4fb2ph4rUT6m2R5ZiZ0RT9xI8 8Lu2mTs+6JP4gL5Xq/f+zlVAvL4ss4RShcc6/ZPLrVUXZlKF4SD9K0lnhxOIELjm ySAE990rbagzxbqVdhR/WN6YMUCoGrz+q1yRyXYFpFGCN6FDnqWw+du1/m969FCE 7W62jZrTqJCFJQz0hm2D =eaLy -----END PGP SIGNATURE----- --------------enig406149B8588C0BF08A813897-- --===============3569975988564552618== 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 --===============3569975988564552618==--