[PATCH v2 6/6] selftests: KVM: Test OS lock behavior

[Oliver Upton]

On Tue, Nov 2, 2021 at 7:53 AM Oliver Upton <oupton at google.com> 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