On 22/11/2019 14:31, Jan Beulich wrote: > On 22.11.2019 14:55, Andrew Cooper wrote: >> On 22/11/2019 13:31, Jan Beulich wrote: >>> On 21.11.2019 23:15, Andrew Cooper wrote: >>>> + /* Fallthrough */ >>>> + case 0x62: /* bound */ >>> Does "bound" really belong on this list? It raising #BR is like >>> insns raising random other exceptions, not like INTO / INT3, >>> where the IDT descriptor also has to have suitable DPL for the >>> exception to actually get delivered (rather than #GP). I.e. it >>> shouldn't make it here in the first place, due to the >>> X86_EVENTTYPE_HW_EXCEPTION check in the caller. >>> >>> IOW if "bound" needs to be here, then all others need to be as >>> well, unless they can't cause any exception at all. >> More experimentation required. BOUND doesn't appear to be special cased >> by SVM, but is by VT-x. VT-x however does throw it in the same category >> as #UD, and identify it to be a hardware exception. >> >> I suspect you are right, and t doesn't want to be here. >> >>>> + case 0x9a: /* call (far, absolute) */ >>>> + case 0xca: /* ret imm16 (far) */ >>>> + case 0xcb: /* ret (far) */ >>>> + case 0xcc: /* int3 */ >>>> + case 0xcd: /* int imm8 */ >>>> + case 0xce: /* into */ >>>> + case 0xcf: /* iret */ >>>> + case 0xea: /* jmp (far, absolute) */ >>>> + case 0xf1: /* icebp */ >>> Same perhaps for ICEBP, albeit I'm less certain here, as its >>> behavior is too poorly documented (if at all). >> ICEBP's #DB is a trap, not a fault, so instruction length is important. > Hmm, this may point at a bigger issue then: Single step and data > breakpoints are traps, too. But of course they can occur with > arbitrary insns. Do their intercepts occur with guest RIP already > updated?
Based on other behaviour, I'm going to guess yes on SVM and no on VT-x. We'll take the #DB intercept, re-inject, and should see a vectoring task switch. The type should match the re-inject, so will be SW_INT/EXC with a length on VT-x, and be HW_EXCEPTION with no length on SVM. Either way, I think the logic presented here will work correctly. > (They wouldn't currently make it here anyway because of > the X86_EVENTTYPE_HW_EXCEPTION check in the caller.) If they do, > are you sure ICEBP-#DB's doesn't? ICEBP itself doesn't get intercepted. Only the resulting #DB does, which will will trigger a #DB-vectoring task switch, irrespective of its exact origin. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
