[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Fwd: Xen-4.1.6.1 backport for XSA156
>>> On 20.11.15 at 18:07, <stefan.bader@xxxxxxxxxxxxx> wrote: > On 20.11.2015 17:54, Jan Beulich wrote: >>>>> On 20.11.15 at 17:15, <stefan.bader@xxxxxxxxxxxxx> wrote: >>> So this is a quick hack I just tried and that keeps the HVM alive: >>> >>> @@ -1294,7 +1288,6 @@ void vmx_inject_hw_exception(int trap, i >>> switch ( trap ) >>> { >>> case TRAP_debug: >>> - type = X86_EVENTTYPE_SW_EXCEPTION; >>> if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) >>> { >>> __restore_debug_registers(curr); >>> @@ -1302,6 +1295,13 @@ void vmx_inject_hw_exception(int trap, i >>> } >>> if ( cpu_has_monitor_trap_flag ) >>> break; >>> + if ( curr->domain->debugger_attached ) >>> + { >>> + /* Debug/Int3: Trap to debugger. */ >>> + domain_pause_for_debugger(); >>> + return; >>> + } >>> + break; >>> case TRAP_int3: >>> if ( curr->domain->debugger_attached ) >>> { >>> >>> Though this looks like an ugly hack and probably is wrong in the other case >>> of >>> TRAP_debug caused by an opcode... >> >> Right, and I'm afraid this case doesn't get handled correctly even on >> -unstable now. But apart from that aspect I think the change above >> is okay. > > Oh, ok. Thanks for the review. I guess then I go with that. At least this > does no longer crash. Actually there's no problem with ICEBP - just like INTnn it isn't itself interceptable (and the injection of vector 0x01 from the x86 emulator path can't fully distinguish between ICEBP and INT $1 in these old versions anyway). So what you have should be good enough, albeit I think I'll code it slightly differently (keeping the fall- through in place). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |