Re: [PATCH v2 for-4.19 3/3] x86/EPT: drop questionable mfn_valid() from epte_get_entry_emt()

["Roger Pau Monné" <roger.pau@citrix.com>]

On Wed, Jun 12, 2024 at 05:14:37PM +0200, Jan Beulich wrote:
> On 12.06.2024 17:00, Roger Pau Monné wrote:
> > On Wed, Jun 12, 2024 at 03:17:38PM +0200, Jan Beulich wrote:
> >> mfn_valid() is RAM-focused; it will often return false for MMIO. Yet
> >> access to actual MMIO space should not generally be restricted to UC
> >> only; especially video frame buffer accesses are unduly affected by such
> >> a restriction.
> >>
> >> Since, as of ???????????? ("x86/EPT: avoid marking non-present entries
> >> for re-configuring"), the function won't be called with INVALID_MFN or,
> >> worse, truncated forms thereof anymore, we call fully drop that check.
> >>
> >> Fixes: 81fd0d3ca4b2 ("x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()")
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > 
> > I do think this is the way to go (removing quirks from
> > epte_get_entry_emt()), however it's a risky change to make at this
> > point in the release.
> > 
> > If this turns out to cause some unexpected damage, it would only
> > affect HVM guests with PCI passthrough and PVH dom0, which I consider
> > not great, but tolerable.
> > 
> > I would be more comfortable with making the change just not so close
> > to the release, but that's where we are.
> 
> Certainly, and I could live with Oleksii revoking his R-a-b (or simply
> not offering it for either of the two prereq changes). Main thing for
> me is - PVH Dom0 finally isn't so horribly slow anymore. However, if it
> doesn't go into the release, then I'd also be unsure about eventual
> backporting.

Thinking about this, it's also likely to fix issues with PCI
passthrough to HVM guests, so I'm quite sure we would need to
backport it.

David Woodhouse already had to fix it once:

https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=30921dc2df3665ca1b2593595aa6725ff013d386

And I'm quite sure this fix was not related to PVH dom0.

Thanks, Roger.