On 26/08/2021 08:26, Jan Beulich wrote: > IVHD entries may specify that ATS is to be blocked for a device or range > of devices. Honor firmware telling us so.
It would be helpful if there was any explanation as to the purpose of this bit. It is presumably to do with SecureATS, but that works by accepting the ATS translation and doing the pagewalk anyway. > > While adding respective checks I noticed that the 2nd conditional in > amd_iommu_setup_domain_device() failed to check the IOMMU's capability. > Add the missing part of the condition there, as no good can come from > enabling ATS on a device when the IOMMU is not capable of dealing with > ATS requests. > > For actually using ACPI_IVHD_ATS_DISABLED, make its expansion no longer > exhibit UB. > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > --- > TBD: I find the ordering in amd_iommu_disable_domain_device() > suspicious: amd_iommu_enable_domain_device() sets up the DTE first > and then enables ATS on the device. It would seem to me that > disabling would better be done the other way around (disable ATS on > device, then adjust DTE). I'd hope that the worst which goes wrong, given the problematic order, is a master abort. But yes - ATS wants disabling on the device first, before the DTE is updated. ~Andrew
