On 11/28/24 7:54 AM, Jason Gunthorpe wrote:
On Wed, Nov 27, 2024 at 08:44:47PM -0800, Nicolin Chen wrote:
On Wed, Nov 27, 2024 at 11:29:06PM -0500, Donald Dutile wrote:
On 11/27/24 5:21 AM, Shameerali Kolothum Thodi wrote:
W.r.t naming, maybe something related to "hardware-accelerated"?
Given that 'accel' has been used for hw-acceleration elsewhere, that seems
like a reasonable 'mode'.
But, it needs a paramater to state was is being accelerated.
i.e., the more global 'accel=kvm' has 'kvm'.
I was thinking more like calling this hw accelerated nested SMMUv3 emulation
as 'smmuv3-accel'. This avoids confusion with the already existing
'iommu=smmuv3' that also has a nested emulation support.
ie,
-device arm-smmuv3-accel,id=smmuv1,bus=pcie.1 \
..
I -think- you are saying below, that we have to think a bit more about this
device tagging. I'm thinking more like
- device arm-smmuv3,accel=<vcmdq>,id=smmu1,bus=pcie.1 \
I wonder if we really need a "vcmdq" enabling/disabling option?
Jason's suggested approach for a vIOMMU allocation is to retry-
on-failure, so my draft patches allocate a TEGRA241_CMDQV type
of vIOMMU first, and then fall back to a regular SMMUV3 type if
it fails. So, a host that doesn't have a VCMDQ capability could
still work with the fallback/default pathway.
It needs to be configurable so the VM can be configured in a
consistent way across nodes
Yes.
To expound further, one wants to be able to define an 'acceptable'
VM criteria, so libvirt (or OpenStack?) can find and generate the list
of 'acceptable nodes', priori typically, that can be a match for the
acceptance criteria.
Conversely, if one specifies a set of systems that one wants to be able
to migrate across, then libvirt needs to find and select/set the
features|attributes
that enable the VM to migrate in a compatible way.
autodetection of host features is nice for experimenting but scale
deployments should precisely specify every detail about the VM and not
rely on host detection. Otherwise the VM instance type will be ill
defined..
Jason
