[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH for-4.12] x86/svm: Fix handling of ICEBP intercepts

>>> On 01.02.19 at 15:49, <andrew.cooper3@xxxxxxxxxx> wrote:
> c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
> ICEBP debug exceptions, but didn't account for the fact that
> svm_get_insn_len() (previously __get_instruction_length) can fail and may
> already raise #GP for the guest.
> If svm_get_insn_len() fails, return back to guest context rather than
> continuing and mistaking a trap-style VMExit for a fault-style one.

My reading of the last part of this sentence is that the exit in
question is a trap-style one. Is my English failing me here?
Because if so, why would there be any call to svm_get_insn_len()
in the first place? For a trap-style exit guest RIP should already
point past the insn, and hence the debug mode checking ought
to never succeed (unless there's a second ICEBP following the
first one immediately).

If, otoh, it really is a fault-style exit (which was my understanding
so far), how is exiting back to guest context going to do any
good, if svm_get_insn_len() did _not_ raise #GP(0)? We'd just
see the same exit right away.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.