Re: [PATCH v2] x86/P2M: synchronize fast and slow paths of p2m_get_page_from_gfn()

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Mar 27, 2025 at 10:24:02AM +0100, Jan Beulich wrote:
> On 27.03.2025 10:00, Roger Pau Monné wrote:
> > On Tue, Mar 25, 2025 at 08:17:04AM +0100, Jan Beulich wrote:
> >> Handling of both grants and foreign pages was different between the two
> >> paths.
> >>
> >> While permitting access to grants would be desirable, doing so would
> >> require more involved handling; undo that for the time being. In
> >> particular the page reference obtained would prevent the owning domain
> >> from changing e.g. the page's type (after the grantee has released the
> >> last reference of the grant). Instead perhaps another reference on the
> >> grant would need obtaining. Which in turn would require determining
> >> which grant that was.
> >>
> >> Foreign pages in any event need permitting on both paths.
> > 
> > I've been wondering about this, and AFAICT the PV equivalent of this
> > function (the tail of get_page_from_gfn()) is much more limited in
> > that it just allows access to domain owned RAM or MMIO that has a
> > backing page (I expect mostly for the low 1MB?).
> > 
> > However for HVM domains we allow to take references to foreign mapped
> > pages and taking references to MMIO pages is not permitted.
> > 
> > Should the tail of get_page_from_gfn() also be adjusted to make use of
> > the newly introduced get_page_from_mfn_and_type(), thus unifying the
> > logic for both PV and HVM?
> 
> There's no (proper) use of P2M types in PV, so I don't think using this
> function is viable for PV. In particular we'd never observe p2m_foreign
> in PV, if I'm not mistaken.

Indeed, p2m types are just occasionally faked for PV, like in
get_page_from_gfn().

> > Could possibly be done in a separate change, I'm just trying to
> > understand why we have this seemingly different handling for PV vs
> > HVM.
> 
> The difference is because access to foreign pages was hacked in to work
> for PVH in a much different (and imo yet more hacky) way than it was
> made work far longer ago for PV. The crucial part of that is in
> get_page_from_l1e(), so get_page_from_gfn() isn't that relevant there
> (I think).

OK.  I'm kind of surprised we need foreign handling for HVM and not
for PV in get_page_from_gfn(), as even with specific handling of
foreign pages in get_page_from_l1e(), the former is used in a lot of
places that don't seem obviously tied or gated to a call to
get_page_from_l1e().

For example the XEN_DOMCTL_getpageframeinfo3 usage of
get_page_from_gfn() will have different results when used against a
foreign page depending on whether the caller is a PV or an HVM
domain.

Thanks, Roger.