From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v2 for-4.19 3/3] x86/EPT: drop questionable mfn_valid() from epte_get_entry_emt()
Date: Wed, 12 Jun 2024 17:27:16 +0200 [thread overview]
Message-ID: <Zmm-VGEvAecY4UlV@macbook> (raw)
In-Reply-To: <07d38484-dda3-4494-9dbb-75d4d2dbc3c3@suse.com>
On Wed, Jun 12, 2024 at 05:14:37PM +0200, Jan Beulich wrote:
> On 12.06.2024 17:00, Roger Pau Monné wrote:
> > I wonder if you should explicitly mention that if adding the
> > mfn_valid() check was done to ensure all mappings to MMIO are created
> > with effective UC caching attribute it won't be fully correct either.
> > Xen could map those using a different effective caching attribute by
> > virtue of host MTRRs being in effect plus Xen chosen PAT attributes.
>
> Well, the mfn_valid() can't have been there to cover _all_ MMIO. It was
> maybe a flawed initial attempt at doing so, and then wasn't properly
> adjusted / dropped. So overall - no, I don't think extending the
> description with anything along the lines of the above would make a lot
> of sense.
I realized myself when writing the paragraph that I wouldn't even know
how to word it properly, neither it would be much helpful without
knowing the exact intention the mfn_valid() check was added for.
Thanks, Roger.
next prev parent reply other threads:[~2024-06-12 15:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-12 13:15 [PATCH v2 for-4.19 0/3] x86/EPT: avoid undue forcing of MMIO accesses to UC Jan Beulich
2024-06-12 13:16 ` [PATCH v2 for-4.19 1/3] x86/EPT: correct special page checking in epte_get_entry_emt() Jan Beulich
2024-06-12 14:11 ` Roger Pau Monné
2024-06-12 14:47 ` Jan Beulich
2024-06-12 15:02 ` Roger Pau Monné
2024-06-12 15:06 ` Jan Beulich
2024-06-13 14:38 ` Oleksii K.
2024-06-12 13:16 ` [PATCH v2 for-4.19 2/3] x86/EPT: avoid marking non-present entries for re-configuring Jan Beulich
2024-06-12 14:38 ` Roger Pau Monné
2024-06-12 14:53 ` Jan Beulich
2024-06-12 15:23 ` Roger Pau Monné
2024-06-13 14:39 ` Oleksii K.
2024-06-12 13:17 ` [PATCH v2 for-4.19 3/3] x86/EPT: drop questionable mfn_valid() from epte_get_entry_emt() Jan Beulich
2024-06-12 15:00 ` Roger Pau Monné
2024-06-12 15:14 ` Jan Beulich
2024-06-12 15:27 ` Roger Pau Monné [this message]
2024-06-13 7:32 ` Roger Pau Monné
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=Zmm-VGEvAecY4UlV@macbook \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=oleksii.kurochko@gmail.com \
--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.