[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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |