On Wed, Feb 11, 2026 at 07:14:40PM +0100, Eric Auger wrote:
> On 2/11/26 7:07 PM, Nicolin Chen wrote:
> > On Wed, Feb 11, 2026 at 08:34:13AM +0000, Shameer Kolothum wrote:
> >> 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.
> > [...]
> >> @@ -1605,6 +1605,10 @@ static MemTxResult smmu_writel(SMMUv3State *s,
> >> hwaddr offset,
> >> s->cr0ack = data & ~SMMU_CR0_RESERVED;
> >> /* in case the command queue has been enabled */
> >> smmuv3_cmdq_consume(s, &local_err);
> >> + /* Allocate vEVENTQ if EventQ is enabled and a vIOMMU is
> >> available */
> > Nit: though it is just following smmuv3_cmdq_consume(), it'd be
> > likely clearer to verify the EVENTQEN in the callers.
> >
> >> + if (local_err == NULL) {
> > Does eventq need to rely on !local_err from cmdq?
> if local_err is NULL we can safely use it, no? Or maybe I miss your
> point. maybe test !local_err directly?
Point is: if local_err isn't NULL, why can't we allocate vEVENTQ?
E.g. if IOMMU_HWPT_INVALIDATE fails, yes there is something wrong
with the CMDQ, yet it shouldn't block vEVENTQ allocation?
> >> + smmuv3_accel_alloc_veventq(s, &local_err);
> >> + }
> > Should probably validate s->accel before calling it?
> it is done in smmuv3_accel_alloc_veventq now
Oh, I just realized I was looking at the v4 branch..
Thanks
Nicolin
