> -----Original Message----- > From: Eric Auger <[email protected]> > Sent: 26 May 2026 14:53 > To: Shameer Kolothum Thodi <[email protected]>; qemu- > [email protected]; [email protected] > Cc: [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]; Krishnakant Jaju > <[email protected]>; [email protected] > Subject: Re: [PATCH v5 20/32] hw/arm/tegra241-cmdqv: Use mmap'd VINTF > page0 as VCMDQ backing > > External email: Use caution opening links or attachments > > > On 5/26/26 3:00 PM, Shameer Kolothum Thodi wrote: > >> the access is dropped with no Fault/Interrupt." > > "While the software can program the Virtual CMDQ(s) directly using the > > direct VCMDQ aperture (and not through the Virtual Interface), it is > > required that the VCMDQ be allocated to a Virtual Interface before it > > is used to send commands to the SMMU." > > > > Assuming your question is regarding the above quote: > > > > The quote is about the direct aperture and says the software "can > > program the Virtual CMDQ(s) directly using the direct VCMDQ aperture", > > and only the "send commands to the SMMU" step is gated by VINTF > > allocation. If direct-aperture writes were also dropped for unallocated > > VCMDQs, the "can program directly" wording wouldn't be meaningful. > > > > "Can program" behaviour: > > > > write 0x10 -> A_VCMDQ1_PROD_INDX > > read A_VCMDQ1_PROD_INDX // read returns 0x10 > > > > > > "Drop" behaviour: > > > > write 0x10 -> A_VCMDQ1_PROD_INDX > > read A_VCMDQ1_PROD_INDX // read returns 0 or undefined > > > > Hope this answers your question. let me know if not. > > On my end, I read that the software can use either the direct view or > the VINTF view as long as the cmdqv is mapped. And if the vcmdq is not > mapped we are not really told what happens. > But anyway this use case of using the direct view looks pretty marginal, > doesn't it.
Yes, the direct aperture read/write isn't an expected common use case. So feel free to interpret it as you agree with Nicolin and > HW experts. Thanks. I will keep it as is and have another look at the "overview" section to improve the description of this. Thanks, Shameer
