On 04/02/2019 09:16, Jan Beulich wrote: >>>> On 01.02.19 at 18:09, <andrew.coop...@citrix.com> wrote: >> On 01/02/2019 16:55, Jan Beulich wrote: >>>>>> On 01.02.19 at 17:25, <andrew.coop...@citrix.com> wrote: >>>> If it were just getting insn_len incorrectly as 0, then the guest would >>>> livelock as we wouldn't inject the #DB with trap semantics it requires, >>> I'm confused again: Why trap semantics? The ICEBP has fault >>> semantics as you confirmed above. >> The ICEBP intercept has fault semantics. An ICEBP instruction executing >> in the guest has trap semantics. > Oh, okay - I was mis-remembering this aspect. > >>>> but as the #GP is already raised, this will combine to #DF. >>> How that? #DB is a benign exception, so according to the table on the >>> #DF page in the SDM, with #GP it shouldn't combine to #DF. >> #GP is raised first. It is contributory. >> >> A subsequent #DB getting raised causes #GP to turn into #DF. > That's based on what?
Based on actually trying this error scenario. (d1) --- Xen Test Framework --- (d1) Environment: HVM 64bit (Long mode 4 levels) (d1) Hello World (XEN) ** Got ICEBP intercept (d1) ****************************** (d1) PANIC: Unhandled exception at 0046:0000000000000008 (d1) Vec 8 #DF[4740] (d1) ****************************** Clearly something is off-by-one in the eventual stack frame, which probably means we've got a a bug in svm_inject_event(). I suspect the escalation to #DF doesn't overwrite the #DB's "no error code" information, but I've not investigated yet. > The table on the #DF page clearly says > otherwise, at least according to my reading. Hmm - so it does. Looks like we've got a 3rd bug, in the general exception combining logic. > But in the end there shouldn't be any attempt to inject #DB anyway > when #GP is already pending, irrespective of the fact that this #GP > is non-architectural. Correct. That bug is what this patch is fixing. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
