qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable nested S


From: Donald Dutile
Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable nested SMMUv3
Date: Tue, 17 Dec 2024 13:36:14 -0500
User-agent: Mozilla Thunderbird



On 12/13/24 8:19 AM, Daniel P. Berrangé wrote:
On Fri, Dec 13, 2024 at 08:46:42AM -0400, Jason Gunthorpe wrote:
On Fri, Dec 13, 2024 at 12:00:43PM +0000, Daniel P. Berrangé wrote:
On Fri, Nov 08, 2024 at 12:52:37PM +0000, Shameer Kolothum via wrote:
Hi,

This series adds initial support for a user-creatable "arm-smmuv3-nested"
device to Qemu. At present the Qemu ARM SMMUv3 emulation is per machine
and cannot support multiple SMMUv3s.

In order to support vfio-pci dev assignment with vSMMUv3, the physical
SMMUv3 has to be configured in nested mode. Having a pluggable
"arm-smmuv3-nested" device enables us to have multiple vSMMUv3 for Guests
running on a host with multiple physical SMMUv3s. A few benefits of doing
this are,

I'm not very familiar with arm, but from this description I'm not
really seeing how "nesting" is involved here. You're only talking
about the host and 1 L1 guest, no L2 guest.

nesting is the term the iommu side is using to refer to the 2
dimensional paging, ie a guest page table on top of a hypervisor page
table.

Nothing to do with vm nesting.

Ok, that naming is destined to cause confusion for many, given the
commonly understood use of 'nesting' in the context of VMs...

Also what is the relation between the physical SMMUv3 and the guest
SMMUv3 that's referenced ? Is this in fact some form of host device
passthrough rather than nesting ?

It is an acceeleration feature, the iommu HW does more work instead of
the software emulating things. Similar to how the 2d paging option in
KVM is an acceleration feature.

All of the iommu series on vfio are creating paravirtualized iommu
models inside the VM. They access various levels of HW acceleration to
speed up the paravirtualization.

... describing it as a HW accelerated iommu makes it significantly clearer
to me what this proposal is about. Perhaps the device is better named as
"arm-smmuv3-accel" ?

I'm having deja-vu! ;-)
Thanks for echo-ing my earlier statements in this patch series about the use of 
'nested'.
and the better use of 'accel' in these circumstances.
Even 'accel' on an 'arm-smmuv3' is a bit of a hammer, as there can be multiple 
accel's features
&/or implementations... I would like to see the 'accel' as a parameter to 
'arm-smmuv3', and not
a complete name-space onto itself, so we can do things like 'accel=cmdvq', 
accel='2-level', ...

and for libvirt's sanity, a way to get those hw features from sysfs for
(possible) migration-compatibility testing.


With regards,
Daniel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]