| Message ID | 7607c5f7-772a-4c49-b2df-19f32ec2180b@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86/EPT: avoid undue forcing of MMIO accesses to UC | expand |
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: > > 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.
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.
--- 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().
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).