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>
Subject: Re: [PATCH 3/3] x86/P2M: don't include MMIO_DM in p2m_is_valid()
Date: Mon, 10 Mar 2025 16:25:31 +0100 [thread overview]
Message-ID: <Z88Ea1Qvork6ytkw@macbook.local> (raw)
In-Reply-To: <2c9885d4-4a9f-4998-b0fa-15c17115fa1e@suse.com>
On Wed, Feb 26, 2025 at 12:53:14PM +0100, Jan Beulich wrote:
> MMIO_DM specifically marks pages which aren't valid, much like INVALID
> does. Dropping the type from the predicate
> - (conceptually) corrects _sh_propagate(), where the comment says that
> "something valid" is needed (the only call path not passing in RAM_RW
> would pass in INVALID_GFN along with MMIO_DM),
> - is benign to the use in sh_page_fault(), where the subsequent
> mfn_valid() check would otherwise cause the same bail-out code path to
> be taken,
> - is benign to all three uses in p2m_pt_get_entry(), as MMIO_DM entries
> will only ever yield non-present entries, which are being checked for
> earlier,
> - is benign to sh_unshadow_for_p2m_change(), for the same reason,
> - is benign to gnttab_transfer() with EPT not in use, again because
> MMIO_DM entries will only ever yield non-present entries, and
> INVALID_MFN is returned for those anyway by p2m_pt_get_entry().
> - for gnttab_transfer() with EPT in use (conceptually) corrects the
> corner case of a page first being subject to XEN_DMOP_set_mem_type
> converting a RAM type to MMIO_DM (which retains the MFN in the entry),
> and then being subject to GNTTABOP_transfer, except that steal_page()
> would later make the operation fail unconditionally anyway.
>
> While there also drop the unused (and otherwise now redundant)
> p2m_has_emt().
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
It's tightening an existing check (making it more restrictive), so as
long as current users can deal with it.
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Thanks, Roger.
next prev parent reply other threads:[~2025-03-10 15:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-26 11:51 [PATCH 0/3] x86/P2M: assorted corrections Jan Beulich
2025-02-26 11:52 ` [PATCH 1/3] x86/P2M: synchronize fast and slow paths of p2m_get_page_from_gfn() Jan Beulich
2025-03-10 14:53 ` Roger Pau Monné
2025-03-11 8:44 ` Jan Beulich
2025-03-11 9:01 ` Roger Pau Monné
2025-02-26 11:52 ` [PATCH 2/3] x86/P2M: correct old entry checking in p2m_remove_entry() Jan Beulich
2025-03-10 15:16 ` Roger Pau Monné
2025-03-10 15:21 ` Roger Pau Monné
2025-02-26 11:53 ` [PATCH 3/3] x86/P2M: don't include MMIO_DM in p2m_is_valid() Jan Beulich
2025-03-10 15:25 ` Roger Pau Monné [this message]
2025-03-11 22:16 ` [REGRESSION] Re: [PATCH 0/3] x86/P2M: assorted corrections Andrew Cooper
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=Z88Ea1Qvork6ytkw@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.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.