| Message ID | 72496fb7-8835-4d45-bd92-7e7d612861c7@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | VT-d: SATC handling and ATS tidying | expand |
On Mon, Feb 05, 2024 at 02:56:14PM +0100, Jan Beulich wrote: > When the flag is set, permit Dom0 to control the device (no worse than > what we had before and in line with other "best effort" behavior we use > when it comes to Dom0), but suppress passing through to DomU-s unless > ATS can actually be enabled for such devices. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > Is ats_device() using acpi_find_matched_atsr_unit() unconditionally > actually correct? Shouldn't that check be skipped for root complex > integrated devices? Yes, I think so, ATSR only lists root ports supporting ATS, because the root complex is assumed to always be ATS capable. None of this seems to be working then for PCIe endpoints directly in the root complex, as ats_device() will always return 0? > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -225,7 +225,10 @@ exceptions (watchdog NMIs and unexpected > > Default: `false` > > Permits Xen to set up and use PCI Address Translation Services. This is a > -performance optimisation for PCI Passthrough. > +performance optimisation for PCI Passthrough. Note that firmware may indicate > +that certain devices need to have ATS enabled for proper operation. For such > +devices ATS will be enabled by default, unless the option is used in its > +negative form. I'm kind of worried that we add this support while maintaining the WARNING below. If I was an admin I would certainly be worried whether my system could lock-up during normal operations, even with the devices assigned to dom0 and not a malicious domain. I know that enabling ATS is forced on us from DMAR, but still. > **WARNING: Xen cannot currently safely use ATS because of its synchronous wait > loops for Queued Invalidation completions.** > --- a/xen/drivers/passthrough/vtd/dmar.c > +++ b/xen/drivers/passthrough/vtd/dmar.c > @@ -254,6 +254,24 @@ struct acpi_atsr_unit *acpi_find_matched > return all_ports; > } > > +const struct acpi_satc_unit *acpi_find_matched_satc_unit( > + const struct pci_dev *pdev) > +{ > + const struct acpi_satc_unit *satc; > + > + list_for_each_entry ( satc, &acpi_satc_units, list ) > + { > + if ( satc->segment != pdev->seg ) > + continue; > + > + for ( unsigned int i = 0; i < satc->scope.devices_cnt; ++i ) > + if ( satc->scope.devices[i] == pdev->sbdf.bdf ) > + return satc; > + } > + > + return NULL; > +} > + > struct acpi_rhsa_unit *drhd_to_rhsa(const struct acpi_drhd_unit *drhd) > { > struct acpi_rhsa_unit *rhsa; > --- a/xen/drivers/passthrough/vtd/dmar.h > +++ b/xen/drivers/passthrough/vtd/dmar.h > @@ -109,6 +109,8 @@ struct acpi_satc_unit { > > struct acpi_drhd_unit *acpi_find_matched_drhd_unit(const struct pci_dev *); > struct acpi_atsr_unit *acpi_find_matched_atsr_unit(const struct pci_dev *); > +const struct acpi_satc_unit *acpi_find_matched_satc_unit( > + const struct pci_dev *pdev); > > #define DMAR_TYPE 1 > #define RMRR_TYPE 2 > --- a/xen/drivers/passthrough/vtd/iommu.c > +++ b/xen/drivers/passthrough/vtd/iommu.c > @@ -2364,6 +2364,25 @@ static int cf_check intel_iommu_add_devi > if ( ret ) > dprintk(XENLOG_ERR VTDPREFIX, "%pd: context mapping failed\n", > pdev->domain); > + else if ( !pdev->broken ) > + { > + const struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev); > + const struct acpi_satc_unit *satc = acpi_find_matched_satc_unit(pdev); > + > + /* > + * Prevent the device from getting assigned to an unprivileged domain > + * when firmware indicates ATS is required, but ATS could not be enabled > + * (e.g. because of being suppressed via command line option). > + */ I think a safer policy would be to prevent assigning any device that has atc_required set unless opt_ats > 1 (ie: the user has explicitly opted-in to the usage of ATS). While we can't likely avoid ATS being enabled for devices having the ATC_REQUIRED flag, we shouldn't allow passthrough to possibly untrusted guests without notice. Thanks, Roger.
On 08.02.2024 13:42, Roger Pau Monné wrote: > On Mon, Feb 05, 2024 at 02:56:14PM +0100, Jan Beulich wrote: >> When the flag is set, permit Dom0 to control the device (no worse than >> what we had before and in line with other "best effort" behavior we use >> when it comes to Dom0), but suppress passing through to DomU-s unless >> ATS can actually be enabled for such devices. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> --- >> Is ats_device() using acpi_find_matched_atsr_unit() unconditionally >> actually correct? Shouldn't that check be skipped for root complex >> integrated devices? > > Yes, I think so, ATSR only lists root ports supporting ATS, because > the root complex is assumed to always be ATS capable. > > None of this seems to be working then for PCIe endpoints directly in > the root complex, as ats_device() will always return 0? That's my understanding. I've now added a bugfix patch near the front of the series. >> --- a/docs/misc/xen-command-line.pandoc >> +++ b/docs/misc/xen-command-line.pandoc >> @@ -225,7 +225,10 @@ exceptions (watchdog NMIs and unexpected >> > Default: `false` >> >> Permits Xen to set up and use PCI Address Translation Services. This is a >> -performance optimisation for PCI Passthrough. >> +performance optimisation for PCI Passthrough. Note that firmware may indicate >> +that certain devices need to have ATS enabled for proper operation. For such >> +devices ATS will be enabled by default, unless the option is used in its >> +negative form. > > I'm kind of worried that we add this support while maintaining the > WARNING below. If I was an admin I would certainly be worried whether > my system could lock-up during normal operations, even with the > devices assigned to dom0 and not a malicious domain. > > I know that enabling ATS is forced on us from DMAR, but still. I'm with you; see below. >> --- a/xen/drivers/passthrough/vtd/iommu.c >> +++ b/xen/drivers/passthrough/vtd/iommu.c >> @@ -2364,6 +2364,25 @@ static int cf_check intel_iommu_add_devi >> if ( ret ) >> dprintk(XENLOG_ERR VTDPREFIX, "%pd: context mapping failed\n", >> pdev->domain); >> + else if ( !pdev->broken ) >> + { >> + const struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev); >> + const struct acpi_satc_unit *satc = acpi_find_matched_satc_unit(pdev); >> + >> + /* >> + * Prevent the device from getting assigned to an unprivileged domain >> + * when firmware indicates ATS is required, but ATS could not be enabled >> + * (e.g. because of being suppressed via command line option). >> + */ > > I think a safer policy would be to prevent assigning any device that > has atc_required set unless opt_ats > 1 (ie: the user has explicitly > opted-in to the usage of ATS). > > While we can't likely avoid ATS being enabled for devices having the > ATC_REQUIRED flag, we shouldn't allow passthrough to possibly > untrusted guests without notice. Switched to that model, including respective wording in the cmdline doc. Jan
--- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -225,7 +225,10 @@ exceptions (watchdog NMIs and unexpected > Default: `false` Permits Xen to set up and use PCI Address Translation Services. This is a -performance optimisation for PCI Passthrough. +performance optimisation for PCI Passthrough. Note that firmware may indicate +that certain devices need to have ATS enabled for proper operation. For such +devices ATS will be enabled by default, unless the option is used in its +negative form. **WARNING: Xen cannot currently safely use ATS because of its synchronous wait loops for Queued Invalidation completions.** --- a/xen/drivers/passthrough/vtd/dmar.c +++ b/xen/drivers/passthrough/vtd/dmar.c @@ -254,6 +254,24 @@ struct acpi_atsr_unit *acpi_find_matched return all_ports; } +const struct acpi_satc_unit *acpi_find_matched_satc_unit( + const struct pci_dev *pdev) +{ + const struct acpi_satc_unit *satc; + + list_for_each_entry ( satc, &acpi_satc_units, list ) + { + if ( satc->segment != pdev->seg ) + continue; + + for ( unsigned int i = 0; i < satc->scope.devices_cnt; ++i ) + if ( satc->scope.devices[i] == pdev->sbdf.bdf ) + return satc; + } + + return NULL; +} + struct acpi_rhsa_unit *drhd_to_rhsa(const struct acpi_drhd_unit *drhd) { struct acpi_rhsa_unit *rhsa; --- a/xen/drivers/passthrough/vtd/dmar.h +++ b/xen/drivers/passthrough/vtd/dmar.h @@ -109,6 +109,8 @@ struct acpi_satc_unit { struct acpi_drhd_unit *acpi_find_matched_drhd_unit(const struct pci_dev *); struct acpi_atsr_unit *acpi_find_matched_atsr_unit(const struct pci_dev *); +const struct acpi_satc_unit *acpi_find_matched_satc_unit( + const struct pci_dev *pdev); #define DMAR_TYPE 1 #define RMRR_TYPE 2 --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -2364,6 +2364,25 @@ static int cf_check intel_iommu_add_devi if ( ret ) dprintk(XENLOG_ERR VTDPREFIX, "%pd: context mapping failed\n", pdev->domain); + else if ( !pdev->broken ) + { + const struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev); + const struct acpi_satc_unit *satc = acpi_find_matched_satc_unit(pdev); + + /* + * Prevent the device from getting assigned to an unprivileged domain + * when firmware indicates ATS is required, but ATS could not be enabled + * (e.g. because of being suppressed via command line option). + */ + if ( satc && satc->atc_required && + (!drhd || ats_device(pdev, drhd) <= 0 || + !pci_ats_enabled(pdev->seg, pdev->bus, pdev->devfn)) ) + { + printk(XENLOG_WARNING "ATS: %pp is not eligible for pass-through\n", + &pdev->sbdf); + pdev->broken = true; + } + } return ret; } @@ -2375,12 +2394,27 @@ static int cf_check intel_iommu_enable_d pci_vtd_quirk(pdev); - if ( ret <= 0 ) - return ret; + if ( ret <= 0 || + (ret = enable_ats_device(pdev, &drhd->iommu->ats_devices)) < 0 ) + { + const struct acpi_satc_unit *satc = acpi_find_matched_satc_unit(pdev); + + /* + * Prevent the device from getting assigned to an unprivileged domain + * when firmware indicates ATS is required, but ATS use was disabled + * via command line option. + */ + if ( satc && satc->atc_required && !pdev->broken ) + { + printk(XENLOG_WARNING "ATS: %pp is not eligible for pass-through\n", + &pdev->sbdf); + pdev->broken = true; + } - ret = enable_ats_device(pdev, &drhd->iommu->ats_devices); + return ret; + } - return ret >= 0 ? 0 : ret; + return 0; } static int cf_check intel_iommu_remove_device(u8 devfn, struct pci_dev *pdev) --- a/xen/drivers/passthrough/vtd/x86/ats.c +++ b/xen/drivers/passthrough/vtd/x86/ats.c @@ -44,9 +44,10 @@ struct acpi_drhd_unit *find_ats_dev_drhd int ats_device(const struct pci_dev *pdev, const struct acpi_drhd_unit *drhd) { struct acpi_drhd_unit *ats_drhd; + const struct acpi_satc_unit *satc; int pos; - if ( opt_ats <= 0 || !iommu_qinval ) + if ( !opt_ats || !iommu_qinval ) return 0; if ( !ecap_queued_inval(drhd->iommu->ecap) || @@ -56,6 +57,10 @@ int ats_device(const struct pci_dev *pde if ( !acpi_find_matched_atsr_unit(pdev) ) return 0; + satc = acpi_find_matched_satc_unit(pdev); + if ( opt_ats < 0 && (!satc || !satc->atc_required) ) + return 0; + ats_drhd = find_ats_dev_drhd(drhd->iommu); pos = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ATS);
When the flag is set, permit Dom0 to control the device (no worse than what we had before and in line with other "best effort" behavior we use when it comes to Dom0), but suppress passing through to DomU-s unless ATS can actually be enabled for such devices. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- Is ats_device() using acpi_find_matched_atsr_unit() unconditionally actually correct? Shouldn't that check be skipped for root complex integrated devices?