Re: [PATCH v2 0/7] hw/arm/smmuv3-accel: Resolve AUTO properties

["Cédric Le Goater" <clg@redhat.com>]

Hello Shameer,

On 5/5/26 09:59, Shameer Kolothum Thodi wrote:
> Hi Cédric,
> 
>> -----Original Message-----
>> From: Cédric Le Goater <clg@redhat.com>
>> Sent: 04 May 2026 15:58
>> To: Nathan Chen <nathanc@nvidia.com>; qemu-arm@nongnu.org; qemu-
>> devel@nongnu.org
>> Cc: Eric Auger <eric.auger@redhat.com>; Peter Maydell
>> <peter.maydell@linaro.org>; Marcel Apfelbaum
>> <marcel.apfelbaum@gmail.com>; Philippe Mathieu-Daudé
>> <philmd@linaro.org>; Yanan Wang <wangyanan55@huawei.com>; Zhao Liu
>> <zhao1.liu@intel.com>; Shameer Kolothum Thodi
>> <skolothumtho@nvidia.com>; Matt Ochs <mochs@nvidia.com>; Nicolin Chen
>> <nicolinc@nvidia.com>
>> Subject: Re: [PATCH v2 0/7] hw/arm/smmuv3-accel: Resolve AUTO properties
>>
>> External email: Use caution opening links or attachments
>>
>>
>> Hello Nathan,
>>
>> On 4/22/26 22:43, Nathan Chen wrote:
>>> Hi,
>>>
>>> This series introduces support for resolving 'auto' for arm-smmuv3
>>> accelerated mode's ATS, RIL, SSIDSIZE, and OAS feature properties
>>> based on host IOMMU capabilities. This is dependent on the series [0]
>>> for changing these property types to accept 'auto' values.
>>>
>>> Accelerated SMMUv3 Address Translation Services support is derived
>>> from IDR0, Range Invalidation support is derived from IDR3, Substream
>>> ID size is derived from IDR1, and output address space is derived from
>>> IDR5.
>>>
>>> The default values are set to 'auto' for all properties. If accel=off
>>> and the values are set to 'auto' or are omitted and resolve to 'auto',
>>> the default property values defined in smmuv3_init_id_regs() for OAS
>>> and RIL will remain unchanged, while SSIDSIZE and ATS values will
>>> remain initialized at 0.
>>>
>>> A complete branch can be found here:
>>> https://github.com/NathanChenNVIDIA/qemu/tree/smmuv3-accel-auto-
>> resolv
>>> e-v2
>>>
>>> Please take a look and let me know your feedback.
>>>
>>> Thanks,
>>> Nathan
>>>
>>> [0]
>>> https://lore.kernel.org/qemu-arm/20260323182454.1416110-1-
>> nathanc@nvid
>>> ia.com/
>>>
>>> Example usage:
>>> qemu-system-aarch64 \
>>>     -object iommufd,id=iommufd0 \
>>>     -machine virt,accel=kvm,gic-version=3,ras=on,highmem-mmio-size=4T \
>>>     -cpu host -smp cpus=4 -m size=16G -nographic \
>>>     -object memory-backend-ram,size=16G,id=m0 \
>>>     -numa node,memdev=m0,cpus=0-3,nodeid=0 \
>>>     -numa node,nodeid=1 -numa node,nodeid=2 -numa node,nodeid=3 -
>> numa node,nodeid=4 \
>>>     -numa node,nodeid=5 -numa node,nodeid=6 -numa node,nodeid=7 -
>> numa node,nodeid=8 \
>>>     -device pxb-pcie,id=pcie.1,bus_nr=1,bus=pcie.0,numa_node=0 \
>>>     -device arm-smmuv3,primary-
>> bus=pcie.1,id=smmuv3.1,accel=on,ats=auto,ssidsize=auto,ril=auto,oas=auto \
>>>     -device pcie-root-port,id=pcie.port1,bus=pcie.1,chassis=1,io-reserve=0 \
>>>     -device vfio-pci-
>> nohotplug,host=0009:06:00.0,bus=pcie.port1,rombar=0,id=dev0,iommufd=i
>> ommufd0,ats=auto \
>>>     -object acpi-generic-initiator,id=gi0,pci-dev=dev0,node=1 \
>>>     -object acpi-generic-initiator,id=gi1,pci-dev=dev0,node=2 \
>>>     -object acpi-generic-initiator,id=gi2,pci-dev=dev0,node=3 \
>>>     -object acpi-generic-initiator,id=gi3,pci-dev=dev0,node=4 \
>>>     -object acpi-generic-initiator,id=gi4,pci-dev=dev0,node=5 \
>>>     -object acpi-generic-initiator,id=gi5,pci-dev=dev0,node=6 \
>>>     -object acpi-generic-initiator,id=gi6,pci-dev=dev0,node=7 \
>>>     -object acpi-generic-initiator,id=gi7,pci-dev=dev0,node=8 \
>>>     -bios /usr/share/AAVMF/AAVMF_CODE.fd \
>>>     -device nvme,drive=nvme0,serial=deadbeaf1,bus=pcie.0 \
>>>     -drive
>> file=/var/lib/libvirt/images/guest.qcow2,index=0,media=disk,format=qcow2,if
>> =none,id=nvme0 \
>>>     -device e1000,romfile=/usr/local/share/qemu/efi-
>> e1000.rom,netdev=net0,bus=pcie.0 \
>>>     -netdev user,id=net0,hostfwd=tcp::5558-:22,hostfwd=tcp::5586-:5586
>>>
>>> Testing:
>>> Basic sanity testing was performed on an NVIDIA Grace platform with
>>> GPU device assignment and running CUDA test apps on the guest.
>>> Observed the feature properties being set based on host IOMMU
>> capabilities.
>>> Verified that the VM boot will fail without a cold-plugged device, and
>>> that a hot-plugged device re-uses the resolved values from the initial
>>> cold-plug. Additional testing and feedback are welcome.
>>
>> It is helpful to have a changelog between different versions of the same series
>> of patches.
>>
>> So, the linux headers and vfio update are not required anymore ?
> 
> Just jumping in as Nathan is on PTO.
> 
> My understanding is that the Linux headers and VFIO updates are not
> included in this series because, based on previous feedback, the
> ATS related VFIO changes will be sent as an independent series.

OK.

The linux headers update is handled here :

   https://lore.kernel.org/qemu-devel/20260427070029.1059386-1-gaosong@loongson.cn/

We should help Song Gao.


The VFIO part adding an ats property :

   https://lore.kernel.org/qemu-devel/20260401010231.4166776-5-nathanc@nvidia.com/

will need an update.

Thanks,

C.