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] x86/PVH: extend checking in hwdom_fixup_p2m()
Date: Mon, 14 Jul 2025 17:00:09 +0200 [thread overview]
Message-ID: <aHUbeTzCLbYdHvXQ@macbook.local> (raw)
In-Reply-To: <664472bb-b375-46eb-999e-34f983275d92@suse.com>
On Mon, Jul 07, 2025 at 04:44:25PM +0200, Jan Beulich wrote:
> We're generally striving to minimize behavioral differences between PV
> and PVH Dom0. Using (just?) is_memory_hole() in the PVH case looks quite
> a bit weaker to me, compared to the page ownership check done in the PV
> case. Extend checking accordingly.
The PV code path is also used by non-priviledged domains, while
pf-fixup is strictly limited to the hardware domain. But I agree that
the page ownership check is possibly better, and more in-line with the
PV counterpart.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
LGTM, I would just request that you also remove the is_memory_hole()
check at the same time.
> ---
> The addition may actually be suitable to replace the use of
> is_memory_hole() here. While dropping that would in particular extend
> coverage to E820_RESERVED regions, those are identity-mapped anyway
> (albeit oddly enough still by IOMMU code).
You could avoid getting E820_RESERVED regions identity mapped if
dom0-iommu=map-reserved=0 is specified on the command line, at which
point your suggestion to use the page ownership check seems better
because it would also allow for pf-fixup to deal with E820_RESERVED
regions.
I think it would be better to remove the is_memory_hole() check if we
introduce the page ownership checking. Otherwise it's kind of
redundant and possibly confusing.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -184,6 +184,22 @@ static int hwdom_fixup_p2m(paddr_t addr)
> !is_memory_hole(_mfn(gfn), _mfn(gfn)) )
> return -EPERM;
>
> + /*
> + * Much like get_page_from_l1e() for PV Dom0 does, check that the page
> + * accessed is actually an MMIO one: Either its MFN is out of range, or
> + * it's owned by DOM_IO.
> + */
> + if ( mfn_valid(_mfn(gfn)) )
> + {
> + struct page_info *pg = mfn_to_page(_mfn(gfn));
We should consider introducing a mfn_t mfn = _mfn(gfn) local variable,
as there's a non-trivial amount of _mfn(gfn) instances. Not that you
need to do it here, just noticed the amount of instances we have of
it.
Thanks, Roger.
next prev parent reply other threads:[~2025-07-14 15:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-07 14:44 [PATCH] x86/PVH: extend checking in hwdom_fixup_p2m() Jan Beulich
2025-07-07 15:01 ` Jan Beulich
2025-07-14 15:00 ` Roger Pau Monné [this message]
2025-07-14 15:22 ` Jan Beulich
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=aHUbeTzCLbYdHvXQ@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.