From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
"Jan Beulich" <jbeulich@suse.com>,
"Roger Pau Monne" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
"Jun Nakajima" <jun.nakajima@intel.com>,
"Kevin Tian" <kevin.tian@intel.com>,
"George Dunlap" <George.Dunlap@citrix.com>,
"Tim (Xen.org)" <tim@xen.org>
Subject: Re: [PATCH v4 02/10] x86/mm: Avoid hard-coding PAT in get_page_from_l1e()
Date: Fri, 16 Dec 2022 10:21:59 -0500 [thread overview]
Message-ID: <Y5yNG6VuzuWDrWyk@itl-email> (raw)
In-Reply-To: <41b74605-bf88-2f56-53f5-033b8934d757@citrix.com>
[-- Attachment #1: Type: text/plain, Size: 3258 bytes --]
On Fri, Dec 16, 2022 at 02:49:33AM +0000, Andrew Cooper wrote:
> On 15/12/2022 11:57 pm, Demi Marie Obenour wrote:
> > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> > index 78b1972e4170cacccc9c37c6e64e76e66a7da87f..802073a01c5cf4dc3cf1d58d28ea4d4e9e8149c7 100644
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -959,15 +959,22 @@ get_page_from_l1e(
> > flip = _PAGE_RW;
> > }
> >
> > - switch ( l1f & PAGE_CACHE_ATTRS )
> > + /* Force cacheable memtypes to UC */
> > + switch ( pte_flags_to_cacheability(l1f) )
> > {
> > - case 0: /* WB */
> > - flip |= _PAGE_PWT | _PAGE_PCD;
> > + case X86_MT_UC:
> > + case X86_MT_UCM:
> > + case X86_MT_WC:
> > + /* not cached */
> > break;
> > - case _PAGE_PWT: /* WT */
> > - case _PAGE_PWT | _PAGE_PAT: /* WP */
> > - flip |= _PAGE_PCD | (l1f & _PAGE_PAT);
> > + case X86_MT_WB:
> > + case X86_MT_WT:
> > + case X86_MT_WP:
> > + /* cacheable, force to UC */
> > + flip |= (l1f & PAGE_CACHE_ATTRS) ^ _PAGE_UC;
> > break;
> > + default:
> > + BUG();
>
> This is guest reachable.
Proof that this is unreachable below. Obviously, feel free to correct
me if the proof is wrong.
pte_flags_to_cacheability() is defined (in this patch) as:
/* Convert from PAT/PCD/PWT embedded in PTE flags to actual cacheability value */
static inline unsigned int pte_flags_to_cacheability(unsigned int flags)
{
unsigned int pat_shift = ((flags & _PAGE_PAT) >> 2) |
(flags & (_PAGE_PCD|_PAGE_PWT));
return 0xFF & (XEN_MSR_PAT >> pat_shift);
}
_PAGE_PAT is 0x80, so (flags & _PAGE_PAT) will either be 0x00 or 0x80,
and ((flags & _PAGE_PAT) >> 2) will either be 0x00 or 0x20. _PAGE_PCD
is 0x10 and _PAGE_PWT ix 0x08, so (flags & (_PAGE_PCD|_PAGE_PWT)) will
either be 0x00, 0x08, 0x10, or 0x18. Therefore, pat_shift will either
be 0x00, 0x08, 0x10, 0x18, 0x20, 0x28, 0x30, or 0x38. This means that
(XEN_MSR_PAT >> pat_shift) is well-defined and will shift XEN_MSR_PAT by
an integer number of bytes, and so (0xFF & (XEN_MSR_PAT >> pat_shift))
(the return value of pte_flags_to_cacheability()) is a single byte
(entry) in XEN_MSR_PAT. Each byte in XEN_MSR_PAT is one of the six
architectural x86 memory types, and there is a case entry in the switch
for each of those types. Therefore, the default case is not reachable.
Q.E.D.
> But the more I think about it, the more I'm not sure this logic is
> appropriate to begin with. I think it needs deleting for the same
> reasons as the directmap cacheability logic needed deleting in XSA-402.
I would prefer this to be in a separate patch series, not least because
I do not consider myself qualified to write a good commit message for it.
This patch series is purely about removing assumptions about Xen’s PAT,
except for the last patch, which I explicitly marked DO NOT MERGE as it
breaks PV guest migration from old Xen at a minimum.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-12-16 15:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-15 23:57 [PATCH v4 00/10] Make PAT handling less brittle Demi Marie Obenour
2022-12-15 23:57 ` [PATCH v4 01/10] x86: Add memory type constants Demi Marie Obenour
2022-12-16 7:42 ` Jan Beulich
2022-12-15 23:57 ` [PATCH v4 02/10] x86/mm: Avoid hard-coding PAT in get_page_from_l1e() Demi Marie Obenour
2022-12-16 2:25 ` Demi Marie Obenour
2022-12-16 7:46 ` Jan Beulich
2022-12-16 2:49 ` Andrew Cooper
2022-12-16 15:21 ` Demi Marie Obenour [this message]
2022-12-15 23:57 ` [PATCH v4 03/10] x86: Replace PAT_* with X86_MT_* Demi Marie Obenour
2022-12-15 23:57 ` [PATCH v4 04/10] x86: Replace MTRR_* constants with X86_MT_* constants Demi Marie Obenour
2022-12-15 23:57 ` [PATCH v4 05/10] x86: Replace EPT_EMT_* constants with X86_MT_* Demi Marie Obenour
2022-12-15 23:57 ` [PATCH v4 06/10] x86: Remove MEMORY_NUM_TYPES and NO_HARDCODE_MEM_TYPE Demi Marie Obenour
2022-12-15 23:57 ` [PATCH v4 07/10] x86: Derive XEN_MSR_PAT from its individual entries Demi Marie Obenour
2022-12-16 7:52 ` Jan Beulich
2022-12-15 23:57 ` [PATCH v4 08/10] x86/mm: make code robust to future PAT changes Demi Marie Obenour
2022-12-15 23:57 ` [PATCH v4 09/10] x86/mm: Reject invalid cacheability in PV guests by default Demi Marie Obenour
2022-12-15 23:57 ` [PATCH v4 10/10] x86: Use Linux's PAT Demi Marie Obenour
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y5yNG6VuzuWDrWyk@itl-email \
--to=demi@invisiblethingslab.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=George.Dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=marmarek@invisiblethingslab.com \
--cc=roger.pau@citrix.com \
--cc=tim@xen.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.