On Tue, Feb 10, 2026 at 12:51:09AM -0800, Shameer Kolothum Thodi wrote:
> > On Fri, Feb 06, 2026 at 02:48:09PM +0000, Shameer Kolothum wrote:
> > > +static uint64_t tegra241_cmdqv_read_vintf(Tegra241CMDQV *cmdqv,
> > hwaddr offset)
> > > +{
> > > + int i;
> > > +
> > > + switch (offset) {
> > > + case A_VINTF0_CONFIG:
> > > + return cmdqv->vintf_config;
> > > + case A_VINTF0_STATUS:
> > > + return cmdqv->vintf_status;
> > > + case A_VINTF0_LVCMDQ_ERR_MAP_0 ...
> > A_VINTF0_LVCMDQ_ERR_MAP_3:
> > > + i = (offset - A_VINTF0_LVCMDQ_ERR_MAP_0) / 4;
> > > + return cmdqv->vintf_cmdq_err_map[i];
> > > + default:
> > > + qemu_log_mask(LOG_UNIMP, "%s unhandled read access at 0x%"
> > PRIx64 "\n",
> > > + __func__, offset);
> > > + return 0;
> >
> > I wonder if we'd still need to implement VINTF0_SID_MATCH/REPLACE
> > registers as it's a part of HW spec. They don't need to associate
> > with anything but register cache alone to support MMIO.
>
> Ok. But I was thinking Guest should not be allowed to configure it as it
> belongs to hypervisor, right?
That's correct for the physical registers. But I think guest could
still MMIO the VM registers? So, what we'd need is just two arrays
in the register cache list to support read/write.
Nicolin
