On 10/28/25 3:03 PM, Jason Gunthorpe wrote:
> 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.
For the record, there is some form of ATS support in virtio-pci devices.
They have an ats property. See hw/virtio/virtio-pci.c and
virtio_pci_ats_ctrl_trigger/pcie_ats_config_write
vhost can be seen as implementing an ATC cache on kernel side.
https://lore.kernel.org/all/[email protected]/
>
>>> 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
>
