On Wed, Jul 16, 2025 at 08:51:23AM -0300, Jason Gunthorpe wrote:
> On Tue, Jul 15, 2025 at 07:57:57PM -0700, Nicolin Chen wrote:
> > > + val = FIELD_EX32(s_accel->info.idr[5], IDR5, GRAN4K);
> > > + if (val < FIELD_EX32(s->idr[5], IDR5, GRAN4K)) {
> > > + s->idr[5] = FIELD_DP32(s->idr[5], IDR5, GRAN4K, val);
> > > + }
> > > + val = FIELD_EX32(s_accel->info.idr[5], IDR5, GRAN16K);
> > > + if (val < FIELD_EX32(s->idr[5], IDR5, GRAN16K)) {
> > > + s->idr[5] = FIELD_DP32(s->idr[5], IDR5, GRAN16K, val);
> > > + }
> > > + val = FIELD_EX32(s_accel->info.idr[5], IDR5, GRAN64K);
> > > + if (val < FIELD_EX32(s->idr[5], IDR5, GRAN64K)) {
> > > + s->idr[5] = FIELD_DP32(s->idr[5], IDR5, GRAN64K, val);
> >
> > Unless there is some conflicts between the QEMU emulation and the
> > SMMU HW, I think we should probably just override these fields to
> > the HW values,
>
> The qemu model should be fully independent of the underlying HW, it
> should not override from HW.
>
> It should check if the underlying supports the model and fail if it
> doesn't.
For every bit? If there is a conflict at a certain field (e.g.
VMM only supports little endian while HW supports big endian),
it must fail.
But here, I mean for these specific fields such as GRANxK and
RIL (range-based invalidation), we should override them with
the HW values. Otherwise, the guest OS seeing RIL for example
will issue TLBI commands that the host can't support. Right?
Thanks
Nicolin
