From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web11.59330.1672736564012063945 for ; Tue, 03 Jan 2023 01:02:44 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=asBwRIxP; spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 83916B80E54 for ; Tue, 3 Jan 2023 09:02:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2FE85C433D2 for ; Tue, 3 Jan 2023 09:02:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672736560; bh=DAirDVKKJ5HxB13zmwUus2ys05CvkG+SntSnuA+yQVE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=asBwRIxP7RCJqPJDGEY/AqQ/f22LqI8GDDdvuRi/4l26m63te/Yq4Q2zafuDDOEMz Bbha++kAVptbnagmDj33TJ9jxaujUP09mvW8Uz5YXStqLO2FTPE6Gcb3CtEa9Vg7wh VG9AQON4f0dAE5mngMsigjim/kw3UdV1rloLrlZ4bwM8lak100gPndHUB+U1faMIEh 4GnhOG/3ScWlDGDRXVacYNuG4J4AB0Ssre/3qUjJBWkMggebLCjiI2IMvYtN7bnO+1 1IcJ8IB+eX3DLP6gbMBAapLi6zRtPS6VRzGiw5oLfjRNKlv05GnIv6roEHnNuoHhsn tbTluFxRARRIg== Received: by mail-lf1-f46.google.com with SMTP id j17so35295610lfr.3 for ; Tue, 03 Jan 2023 01:02:40 -0800 (PST) X-Gm-Message-State: AFqh2krPU26Qomcva/BbHMe9+OR66g44JEzkM4iqeWvdahOdxPWKb7w9 P3Xe9WgSI/1eSdFXJ4ualSMgfOOB1mDb0smr2QI= X-Google-Smtp-Source: AMrXdXu+OCivp9L7K163Lvm5Capq139rNgwVbxX6NkyYbwYcuay/OCAhfs+DsDK2l6UZVoFtapl8L+fFWt06lSO6wG8= X-Received: by 2002:a05:6512:15a3:b0:4bc:bdf5:f163 with SMTP id bp35-20020a05651215a300b004bcbdf5f163mr2135376lfb.583.1672736558191; Tue, 03 Jan 2023 01:02:38 -0800 (PST) MIME-Version: 1.0 References: <20220926082511.2110797-1-ardb@kernel.org> <20220926082511.2110797-13-ardb@kernel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 3 Jan 2023 10:02:27 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v3 12/16] ArmVirtPkg/ArmVirtQemu: enable initial ID map at early boot To: dann frazier Cc: devel@edk2.groups.io, Leif Lindholm , Alexander Graf Content-Type: text/plain; charset="UTF-8" On Thu, 29 Dec 2022 at 22:10, dann frazier wrote: > > On Mon, Sep 26, 2022 at 10:25:07AM +0200, Ard Biesheuvel wrote: > > Now that we have all the pieces in place, switch the AArch64 version of > > ArmVirtQemu to a mode where the first thing it does out of reset is > > enable a preliminary ID map that covers the NOR flash and sufficient > > DRAM to create the UEFI page tables as usual. > > > > The advantage of this is that no manipulation of memory occurs any > > longer before the MMU is enabled, which removes the need for explicit > > coherency management, which is cumbersome and bad for performance. > > > > It also means we no longer need to build all components that may execute > > with the MMU off (including BASE libraries) with strict alignment. > > After this switch, I'm seeing a Synchronous Exception when launching a > VM, though only on old Cavium ThunderX (CN88XX) systems. I used print > debugging to narrow it down to ArmSetTTBR0(). Initially I thought it > might be related to Cavium Erratum 27456, but that doesn't seem to > make sense because the instruction cache isn't enabled until > later. I tried implementing the same workaround as Linux does anyway > (flush caches after the setting ttbr0) without any luck. > > Any idea what is going on there? > I suspect it is in fact the same erratum - the I-cache does get enabled almost immediately after reset, and the use of ASIDs for EL1 mappings looks suspiciously like failure mode that required us to disable KPTI for ThunderX on Linux. It is a bit disappointing to have to add workarounds for obsolete platforms in new code, so if I fix this, it will be gated by a -D build option - is that acceptable to you?