On 12/12/2016 20:23, Doug Evans wrote: > On Tue, Dec 6, 2016 at 3:06 PM, Doug Evans <d...@google.com> wrote: >> Hi. >> >> While qemu's behaviour matches what one would expect from reading >> the docs, it does not match what I'm seeing on h/w. >> Can anyone else confirm what the correct behaviour is here? >> >> --- >> >> The syscall and sysret instructions behave a bit differently: >> TF is checked after the instruction completes. >> This allows the o/s to disable #DB at a syscall by adding TF to FMASK. >> And then when the sysret is executed the #DB is taken "as if" the >> syscall insn just completed. >> >> Signed-off-by: Doug Evans <d...@google.com> > > Ping. > Especially, can anyone confirm the correct behaviour here?
Hi, I haven't look at the patch because QEMU was in freeze. I'll get back to it later this week, hopefully. The best way to provide a testcase would be a patch to kvm-unit-tests (git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git); most of the tests can be used with both QEMU emulation mode and KVM. Paolo > I can provide a testcase with Fuchsia if one likes. > https://fuchsia.googlesource.com/fuchsia/ > It's not that hard to repro - we trip over it because we don't have a #DB IST > and since SYSCALL doesn't change SP we get a double fault on qemu > trying to establish the interrupt frame for the #DB (whereas the #DB shouldn't > happen in the first place - at least when run on the h/w I'm using). > The Intel/AMD docs are *really* unclear on this AFAICT. > > patchwork reference: http://patchwork.ozlabs.org/patch/703373/ >
