Re: [PATCH v4 19/27] hw/arm/smmuv3-accel: Install S1 bypass hwpt on reset

[Nicolin Chen <nicolinc@nvidia.com>]

On Mon, Oct 27, 2025 at 07:51:15AM -0700, Shameer Kolothum wrote:
> > On 10/17/25 1:19 AM, Nicolin Chen wrote:
> > > On Mon, Sep 29, 2025 at 02:36:35PM +0100, Shameer Kolothum wrote:
> > >> When the guest reboots with devices in nested mode (S1 + S2), any
> > QEMU/UEFI
> > >> access to those devices can fail because S1 translation is not valid during
> > >> the reboot. For example, a passthrough NVMe device may hold GRUB boot
> > info
> > >> that UEFI tries to read during the reboot.
> > >>
> > >> Set S1 to bypass mode during reset to avoid such failures.
> > > GBPA is set to bypass on reset so I think it's fine. Yet, maybe the
> > > code should check that.
> > 
> > shouldn't we check its actual value before setting bypass?
> > 
> > By the way the spec says is ABORT is set to 0x0:
> > "Do not abort incoming transactions. Transactions bypass the SMMU with
> > attributes given by other fields in this register."
> > 
> > Wondering about those attributes and they can apply on the host?
> 
> That’s right. There are other attributes there. Currently kernel only
> support,
> 
> * @ste: The first two double words of the user space Stream Table Entry for
>  *       the translation. Must be little-endian.
>  *       Allowed fields: (Refer to "5.2 Stream Table Entry" in SMMUv3 HW Spec)
>  *       - word-0: V, Cfg, S1Fmt, S1ContextPtr, S1CDMax
>  *       - word-1: EATS, S1DSS, S1CIR, S1COR, S1CSH, S1STALLD
> 
> If other attributes make sense, we may have to update kernel. I will add a note
> here, so that we can update it if required. I think Nicolin is looking into this.

According to SMMU spec 6.3 GBPA register's Additional information:
 - If SMMU_IDR1.ATTR_TYPES_OVR == 0, MTCFG, SHCFG, ALLOCCFG are
   effectively fixed as Use incoming and it is IMPLEMENTATION
   SPECIFIC whether these fields read as zero or a previously
   written value. In this case, MemAttr reads as UNKNOWN.
 - If SMMU_IDR1.ATTR_PERMS_OVR == 0, INSTCFG and PRIVCFG are
   effectively fixed as Use incoming and it is IMPLEMENTATION
   SPECIFIC whether these fields read as zero or a previously
   written value.

On the other hand, QEMU seems to set both OVR fields to 0, so all
those "other attributes" wouldn't be necessarily forwarded to the
kernel?

Nicolin