On Thu, 16 Sept 2021 at 18:17, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Thu, 16 Sept 2021 at 17:05, Ard Biesheuvel <a...@kernel.org> wrote: > > I'd argue that compliance with the architecture means that the > > software should not clear RES1 bits > > Architecturally, RES1 means that "software > * Must not rely on the bit reading as 1. > * Must use an SBOP policy to write to the bit." > (SBOP=="should be 1 or preserved", ie you can preserve the existing value, > as in "read register, change some bits, write back", or you can write a 1.) >
OVMF preserves the bit, and does not reason or care about its value. So in this sense, it is compliant. > > but I don't think we can blame it > > for not touching bits that were in in invalid state upon entry. > > SCTLR_EL1.SPAN == 0 is perfectly valid for a CPU that supports the > PAN feature. It's just not the value OVMF wants, so OVMF should > be setting it to what it does want. Also, as the first thing to > run after reset (ie firmware) OVMF absolutely is responsible for > dealing with system registers which have UNKNOWN values out of > reset. > Fair enough. But I'd still suggest fixing this at both ends. > Put another way, if you want to argue that this is an "invalid > state" you need to point to the specification that defines > the valid state that OVMF should see when it is handed control. > > -- PMM
