On Tue, Dec 30, 2025 at 01:47:08AM -0800, Shameer Kolothum wrote: > > From: Nicolin Chen <[email protected]> > > Sent: 29 December 2025 19:50 > > To: Shameer Kolothum <[email protected]> > > Cc: [email protected]; [email protected]; > > [email protected]; [email protected]; Nathan Chen > > <[email protected]>; Matt Ochs <[email protected]>; Jason Gunthorpe > > <[email protected]>; [email protected]; > > [email protected]; [email protected]; Krishnakant Jaju > > <[email protected]> > > Subject: Re: [RFC PATCH 10/16] hw/arm/tegra241-cmdqv: Allocate vEVENTQ > > object > > > > On Wed, Dec 10, 2025 at 01:37:31PM +0000, Shameer Kolothum wrote: > > > @@ -259,11 +305,16 @@ static bool > > tegra241_cmdqv_setup_vcmdq(Tegra241CMDQV *cmdqv, int index, > > > g_free(vcmdq); > > > } > > > > > > + if (!tegra241_cmdqv_alloc_veventq(cmdqv, errp)) { > > > + return false; > > > + } > > > + > > > > I think this should be called in tegra241_cmdqv_alloc_viommu(). > > Should/Can we? _alloc_viommu() will happen before the Guest boot.
I think we can. vEVENTQ only needs vIOMMU ID. It's per VINTF v.s. per VCMDQ (HW_QUEUE). So, it should follow vIOMMU. Basically, we can allocate vIOMMU (VINTF) and its vEVENTQ even if the VINTF doesn't contain any LVCMDQs, which are allocated/mapped to the VINTF later via HW_QUEUE allocations. > Unlike the SMMUv3 vEVENTQ for accel case, we restrict the hotplug > use case when the tegra214-cmdqv is set. And as soon as Guest setup vCMDQ > the vEVENTQ is enabled here. Do you see any issues with this approach? Once guest OS is booting, !tegra241_cmdqv_alloc_veventq will fail tegra241_cmdqv_setup_vcmdq while it cannot break the guest OS any more. Then, the whole thing wouldn't work although guest OS runs? Nicolin
