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

Posted by Shameer Kolothum Thodi 2 weeks ago

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.

Thanks,
Shameer

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

Posted by Cédric Le Goater 2 weeks ago

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.