> -----Original Message----- > From: Nicolin Chen <[email protected]> > Sent: 29 October 2025 04:27 > To: Shameer Kolothum <[email protected]> > Cc: [email protected]; [email protected]; qemu- > [email protected]; [email protected]; Jason Gunthorpe > <[email protected]>; [email protected]; [email protected]; Nathan > Chen <[email protected]>; Matt Ochs <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: [PATCH v4 19/27] hw/arm/smmuv3-accel: Install S1 bypass hwpt > on reset > > 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?
OK. Based on the QEMU OVR value, GBPA now resets to 0x1000, meaning SHCFG = 0b01 (Use incoming). However, in the current vSTE bypass/abort cases, SHCFG is set to 0b00 (Non-shareable). However, I think the SHCFG will be overridden by S2FWB. So, I don’t think we need to modify anything at this stage. In general, though, the kernel might need to propagate some of these attributes, possibly INSTCFG and PRIVCFG, since they are not overridden by S2FWB ? Thanks, Shameer
