On Tue, Nov 2, 2021 at 7:53 AM Oliver Upton <oupton@xxxxxxxxxx> wrote: > > > > I haven't had a change to properly review the series, but this one > > definitely caught my eye. My expectations are that BRK is *not* > > affected by the OS Lock. The ARMv8 ARM goes as far as saying: > > > > <quote> > > Breakpoint Instruction exceptions are enabled regardless of the state > > of the OS Lock and the OS Double Lock. > > </quote> > > > > as well as: > > > > <quote> > > There is no enable control for Breakpoint Instruction exceptions. They > > are always enabled, and cannot be masked. > > </quote> > > /facepalm I had thought I read "Breakpoint Instruction exceptions" in > the list on D2.5 "The effect of powerdown on debug exceptions", > although on second read I most definitely did not. And if I had read > the bottom of the section, I'd of seen one of the quotes. > > > I wonder how your test succeeds, though. > > Probably because the expectations I wrote match the non-architected > behavior I implemented :-) Alright, gave the series a good once over after this and fixed up quite a few things. Unless you're ready for it, I'll hold back for a bit to avoid spamming inboxes. As an FYI, here's the fixes I have queued up: v2 -> v3: - Stop trapping debug exceptions when the OS Lock is enabled, as it does *not* block software breakpoint exceptions (Marc) - Trap accesses to debug registers if the OS Lock is enabled to prevent the guest from wiping out KVM's configuration of MDSCR_EL1 - Update the debug-exceptions test to expect a software breakpoint exception even when the OS Lock is enabled. -- Thanks, Oliver
