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>
---
Considering that we've just declared PVH Dom0 "supported", this may well
qualify for 4.19. The issue was specifically very noticeable there.
---
v2: Different approach (and hence different title and description).

--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -501,12 +501,6 @@ int epte_get_entry_emt(struct domain *d,
         return -1;
     }
 
-    if ( !mfn_valid(mfn) )
-    {
-        *ipat = true;
-        return X86_MT_UC;
-    }
-
     /*
      * Conditional must be kept in sync with the code in
      * {iomem,ioports}_{permit,deny}_access().

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.

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

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.

Thanks, Roger.

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.

> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.

> 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.

Jan

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.

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.