On Tue, Oct 28, 2025 at 02:51:29PM +0100, Eric Auger wrote: > > > On 10/28/25 2:41 PM, Jason Gunthorpe wrote: > > On Tue, Oct 28, 2025 at 02:21:32PM +0100, Eric Auger wrote: > >> > >> On 10/28/25 1:16 PM, Jason Gunthorpe wrote: > >>> On Mon, Oct 27, 2025 at 10:53:10AM -0700, Nicolin Chen wrote: > >>> > >>>> Hmm, that sounds a legit reason, though adding the ATS support to > >>>> the emulated SMMUv3 isn't seemingly a small effort... > >>> What is "emulated ATS" anyhow? > >> I guess it means implementing ATS translation requests and capability to > >> send ATS invalidations. something like: > >> > >> https://lore.kernel.org/all/[email protected]/ > > Why would you even want this? The cover letter didn't explain what the > > point was. > > well I am just concerned about exposing ATS support to emulated EPs > while we actually do not support it.
Sure, that shouldn't be done. There is ACPI/DT tables indicating if the each device supports ATS and qemu should not be marking the emulated EPs as ATS capable in the first place.. However, there is no big work with showing EPs as ATS capable. They don't implement an ATC and there is no concept of "translated address" inside qemu so the only requirement to make it "work" is to just NOP the ATC invalidation SMMU commands for those EPs. > > qemu emulating two levels of IOTLB caching in software, with a > > software page table walk?? Why?? > About the actual use case for ATS emulation you'd rather ask the > contributor, early SW development, IP development? I guess, I assume some OOT driver is trying to model their ATC with more accuracy. Maybe to bolt qemu onto a chip emulator. Jason
