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
