From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Regression: x86/mm: new _PTE_SWP_SOFT_DIRTY bit conflicts with existing use Date: Thu, 22 Aug 2013 11:06:38 +0200 Message-ID: <5215D49E.6000501@canonical.com> References: <5214C524.1050900@citrix.com> <5215DFE302000078000ED8C6@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1814230029806584327==" Return-path: In-Reply-To: <5215DFE302000078000ED8C6@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: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1814230029806584327== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB7E5FA6DCAB3457F492FE6F9" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB7E5FA6DCAB3457F492FE6F9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 22.08.2013 09:54, Jan Beulich wrote: >>>> On 21.08.13 at 19:28, Andy Lutomirski wrote: >> On Wed, Aug 21, 2013 at 6:48 AM, David Vrabel wrote: >>> All, >>> >>> 179ef71c (mm: save soft-dirty bits on swapped pages) introduces a new= >>> PTE bit on x86 _PTE_SWP_SOFT_DIRTY which has the same value as _PTE_P= SE >>> and _PTE_PAT. >>> >>> With a Xen PV guest, the use of the _PTE_PAT will result in the page >>> having unexpected cachability which will introduce a range of subtle >>> performance and correctness issues. Xen programs the entry 4 in the = PAT >>> table with WC so a page that was previously WB will end up as WC. >>> >> >> Kind of off topic, but do you have a summary of how Xen uses the high >> PAT bits? I'm the one who wants WT, and if there's already precedent >> for using the high PAT bits, it'll be helpful. >=20 > Xen's public headers have a comment explaining this, with the > main information being this table: >=20 > * The PAT MSR is as follow (it is a 64-bit value, each entry is 8 bit= s): > * PAT4 PAT0 > * +---+----+----+----+-----+----+----+ > * WC | WC | WB | UC | UC- | WC | WB | <=3D Linux > * +---+----+----+----+-----+----+----+ > * WC | WT | WB | UC | UC- | WT | WB | <=3D BIOS (default when mach= ine boots) > * +---+----+----+----+-----+----+----+ > * WC | WP | WC | UC | UC- | WT | WB | <=3D Xen > * +---+----+----+----+-----+----+----+ That looks odd and I think the kernel arch/x86/xen/mmu.c has a more corre= ct summary. As much as I remember the specs and the usage in Linux, the uppe= r four slots are mirroring the lower 4 ones. That way PTEs don't need to ca= re to what value the PAT bit is set. The BIOS default would result in the same = meaning of PCD and PWT as without PAT. Linux changes it to get WC but otherwise continues to avoid the PAT bit which moves position for large pages. -Stefan >=20 > i.e. Xen is retaining the BIOS (and legacy from non-PAT times) > meaning of the low four entries, putting WC and WP up into > the high half. The fact that the entry 6 is defined to be WC > is perhaps a mistake - it should really be considered reserved > for an eventual future memory type (just like entry 7). It also > seems like entry 6 is documented incorrectly here for Linux and > BIOS. >=20 --------------enigB7E5FA6DCAB3457F492FE6F9 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/ iQIcBAEBCgAGBQJSFdSmAAoJEOhnXe7L7s6j2cYP/iSZchnHk3F/sss3LnzciS1L ZA674A5miC2KNdmbbHiacE8zroIGnqdE4Lld9nGOLgjsxv1W0DaZqdObtMMLLSWo Z1/Bupiw1Qkv7LLxGZMuIbsaa/mRjrx2k1IsKzUG6tRq+20OP4KthMXTGa5V1Zv8 HGwXybuYdZw6guZOfnK8iUL3JybEQRvNbjjAW2fMVfcJRmjeXDaDjgMddNqMZfcG o+Jt8PQtucUdnRH0biHcMwX6tGuoAxeNraC+s4tSZNtJ7MdTsok/TJRdWQV90f0i QnM41LWqWTjO3t5tTfSoo2iyVTjb0Jm+RCgUP2GXq5UIW6dj+L5GPxY7lS96mEsf kLaLTKhpe1fBSQkukjwk3Set24v9z+FjB0zbiSVwCO/olVi7CrwNdQfRtzAS/U2p 4Kr+vpYoB5qby9TFZMZ1pzT7F69NC8zV906JbxfeCTnF3fTxiqdP+xZzDNd1kT46 MmPyi6/mk3RvZ78IF3XBLbASE73YXdlXf3joHi4htmpGG8yHKPNI8oW+6AK0w7Q7 9LPvNByoXkHXw9LaachA6CiojRoQW5qFWhcNU7HBU59FD/Dw+/GKy2r08YsX1szo XDRxx63F80fVzr8jVurpqH45HoTVbkgCTsCH5jnVZlTqxTKEWMaCA4iKZ1oQh6d0 p1JOiTBD1blXAnQIHWNr =vYiX -----END PGP SIGNATURE----- --------------enigB7E5FA6DCAB3457F492FE6F9-- --===============1814230029806584327== 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 --===============1814230029806584327==--