Hi Eric, > -----Original Message----- > From: Eric Auger <[email protected]> > Sent: 27 October 2025 16:59 > To: Shameer Kolothum <[email protected]>; qemu- > [email protected]; [email protected] > Cc: [email protected]; Jason Gunthorpe <[email protected]>; Nicolin > Chen <[email protected]>; [email protected]; [email protected]; > Nathan Chen <[email protected]>; Matt Ochs <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: [PATCH v4 22/27] hw/arm/smmuv3-accel: Add support for ATS > > External email: Use caution opening links or attachments > > > Hi Shameer, > On 9/29/25 3:36 PM, Shameer Kolothum wrote: > > QEMU SMMUv3 does not enable ATS (Address Translation Services) by > default. > > When accelerated mode is enabled and the host SMMUv3 supports ATS, it > can > > be useful to report ATS capability to the guest so it can take advantage > > of it if the device also supports ATS. > > > > Note: ATS support cannot be reliably detected from the host SMMUv3 IDR > > registers alone, as firmware ACPI IORT tables may override them. The > > user must therefore ensure the support before enabling it. > This looks incomplete to me. ATS is a big topic in itself. I would > prefer we do not advertise it until we do not have full support for it > (including emulation). Comparing to > c049bf5bb9dd ("intel_iommu: Add support for ATS") which was recently > contributed we miss at least translation request implementations > (PCIIOMMUOps ats_request_translation callback implementation).
I may be wrong, but from a quick look, these ats_request_translation() only matters for emulated devices, right? For pass-through devices, the translation happens at hardware level IIUC. Not sure, your concern is compatibility with emulation support or breaking any functionality here. > > See: > https://lore.kernel.org/all/20250628180226.133285-11-clement.mathieu-- > [email protected]/#r > > Also in SMMU spec I see other stuff like STE.EATS, ATS skipping stage 1, > ... Here I only see SMMU_CMD_ATC_INV and this is only implemented for > accel. I think I would rather stick to the minimum in this series, ie. > reject in case of ATS mismatch (for testing purpose you will just need a > small hack until we get ATS support), work on ATS enablement in parallel I think that is taken care in kernel. See arm_smmu_validate_vste() in arm-smmu-v3-iommufd.c I will double check that though. Thanks, Shameer
