> -----Original Message----- > From: Nicolin Chen <[email protected]> > Sent: 20 November 2025 21:22 > To: Shameer Kolothum <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; Jason Gunthorpe > <[email protected]>; [email protected]; [email protected]; Nathan > Chen <[email protected]>; Matt Ochs <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > Krishnakant Jaju <[email protected]> > Subject: Re: [PATCH v6 17/33] hw/arm/smmuv3: Add support for providing a > direct MSI doorbell GPA > > On Thu, Nov 20, 2025 at 01:21:57PM +0000, Shameer Kolothum wrote: > > Accelerated SMMUv3 instances rely on the physical SMMUv3 for nested > > translation (Guest Stage-1, Host Stage-2). In this mode the guest’s > > Stage-1 tables are programmed directly into hardware, and QEMU should > > not attempt to walk them for translation since doing so is not reliably > > safe. For vfio-pci endpoints behind such a vSMMU, the only translation > > QEMU is responsible for is the MSI doorbell used during KVM MSI setup. > > > > Add a device property to carry the MSI doorbell GPA from the virt > > machine, and expose it through a new get_msi_direct_gpa PCIIOMMUOp. > > kvm_arch_fixup_msi_route() can then use this GPA directly instead of > > attempting a software walk of guest translation tables. > > > > This enables correct MSI routing with accelerated SMMUv3 while avoiding > > unsafe accesses to page tables. > > > > For meaningful use of vfio-pci devices with accelerated SMMUv3, both KVM > > and a kernel irqchip are required. Enforce this requirement when accel=on > > is selected. > > > > Signed-off-by: Shameer Kolothum <[email protected]> > > Reviewed-by: Nicolin Chen <[email protected]> > > Nits: > > > +++ b/hw/arm/virt.c > > @@ -3052,6 +3052,14 @@ static void > virt_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev, > > /* The new SMMUv3 device is specific to the PCI bus */ > > object_property_set_bool(OBJECT(dev), "smmu_per_bus", true, > NULL); > > } > > + if (object_property_find(OBJECT(dev), "accel") && > > + object_property_get_bool(OBJECT(dev), "accel", &error_abort)) { > > Do we need object_property_find()? A later patch seems to drop it. > Perhaps we shouldn't add it in the first place?
We need that at this stage as we haven't added the "accel" property yet and that will cause "make check" tests to fail without that. We remove it once we introduce "accel" property later. Thanks, Shameer
