On Tue, 24 Feb 2026 15:18:00 +0000 Shameer Kolothum Thodi <[email protected]> wrote:
> > -----Original Message----- > > From: Jonathan Cameron <[email protected]> > > Sent: 24 February 2026 15:02 > > To: Shameer Kolothum Thodi <[email protected]> > > Cc: [email protected]; [email protected]; > > [email protected]; [email protected]; Nicolin Chen > > <[email protected]>; Nathan Chen <[email protected]>; Matt Ochs > > <[email protected]>; Jiandi An <[email protected]>; Jason Gunthorpe > > <[email protected]>; [email protected]; [email protected]; > > Krishnakant Jaju <[email protected]> > > Subject: Re: [PATCH v7 3/5] hw/arm/smmuv3-accel: Allocate vEVENTQ for > > accelerated SMMUv3 devices > > > > External email: Use caution opening links or attachments > > > > > > On Tue, 24 Feb 2026 14:41:08 +0000 > > Shameer Kolothum Thodi <[email protected]> wrote: > > > > > > -----Original Message----- > > > > From: Jonathan Cameron <[email protected]> > > > > Sent: 24 February 2026 14:29 > > > > To: Shameer Kolothum Thodi <[email protected]> > > > > Cc: [email protected]; [email protected]; > > > > [email protected]; [email protected]; Nicolin Chen > > > > <[email protected]>; Nathan Chen <[email protected]>; Matt Ochs > > > > <[email protected]>; Jiandi An <[email protected]>; Jason Gunthorpe > > > > <[email protected]>; [email protected]; [email protected]; > > > > Krishnakant Jaju <[email protected]> > > > > Subject: Re: [PATCH v7 3/5] hw/arm/smmuv3-accel: Allocate vEVENTQ for > > > > accelerated SMMUv3 devices > > > > > > > > External email: Use caution opening links or attachments > > > > > > > > > > > > On Thu, 19 Feb 2026 09:01:01 +0000 > > > > Shameer Kolothum <[email protected]> wrote: > > > > > > > > > From: Nicolin Chen <[email protected]> > > > > > > > > > > When the guest enables the Event Queue and a vIOMMU is present, > > > > > allocate a vEVENTQ object so that host-side events related to the > > > > > vIOMMU can be received and propagated back to the guest. > > > > > > > > > > For cold-plugged devices using SMMUv3 acceleration, the vIOMMU is > > > > > created before the guest boots. In this case, the vEVENTQ is allocated > > > > > when the guest writes to SMMU_CR0 and sets EVENTQEN = 1. > > > > > > > > > > If no cold-plugged device exists at boot (i.e. no vIOMMU initially), > > > > > the vEVENTQ is allocated when a vIOMMU is created, i.e. during the > > > > > first device hot-plug. > > > > > > > > Why do it differently? > > > > > > This is because a vEVENTQ must be associated with a vIOMMU, and > > > iommufd_backend_alloc_veventq() requires a valid viommu_id. > > > > > > A vIOMMU is only created once at least one vfio-pci device is > > > attached. If the VM boots without any cold-plugged devices, no > > > vIOMMU exists at that point. > > > > > > In that case, the vIOMMU is created during the first device > > > hot-plug, so we allocate the vEVENTQ at that time instead. > > > > > > So, the difference in behaviour simply follows when the vIOMMU > > > becomes available. > > > > > > Hope that is clear now. > > Ok. So maybe this is just a description thing that was confusing me. > > The key to my mental model is that both conditions must be met. That > > is SMMU_CR0 has EVENTQEN = 1 set and there is a VFIO device present. > > They happen in different orders in the two cases? > > Yes. And EVENTQEN is set by Guest ARM SMMUv3 driver probe time. > > > > > What guarantees we don't get a hotplug event before the guest has > > set EVENTQEN = 1? > > vEVENTQ needs two things: > > 1) The guest must set EVENTQEN=1. > 2) A vIOMMU must already exist (which happens when a VFIO device is attached). > > EVENTQEN=1 is set by the guest when the SMMUv3 driver probes. > > These two things can happen in either order. > > In the cold-plug case, the vIOMMU already exists before the guest driver > probes. So when the guest sets EVENTQEN=1 during driver probe, we > allocate the vEVENTQ at that time. > > In the hot-plug-first case, the first VFIO hotplug creates the vIOMMU, > possibly before the guest has loaded the SMMUv3 driver. In that case, > we wait until the guest sets EVENTQEN=1 during driver probe, and then > allocate the vEVENTQ. > > So we do not depend on ordering. We just check that both conditions > are true, and allocate when the second one becomes true. Perfect. That explanation works for me. If you respin maybe start the explanation with the full conditions that must be met, then break down why they occur in different orders in the cold and hotplug (after we reach a particular point in guest boot) cases. Jonathan > > Thanks, > Shameer >
