[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting
Very cryptic. Did it fix the bug you originally posted about? -- Keir On 11/05/2009 17:05, "Byrne, John (HP Labs)" <john.l.byrne@xxxxxx> wrote: > The schedule_softirq() does close a hole I wasn't noticing. > > Thanks. > >> -----Original Message----- >> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] >> Sent: Sunday, May 10, 2009 11:52 PM >> To: Byrne, John (HP Labs); xen-devel@xxxxxxxxxxxxxxxxxxx >> Subject: Re: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP >> setting >> >> On 11/05/2009 05:32, "Byrne, John (HP Labs)" <john.l.byrne@xxxxxx> >> wrote: >> >>> Running a heavily modified xen-unstable changset 19590:f80cf52a4fb6 >> with >>> debugger_attached set, I was seeing the debug traps getting lost from >> the >>> EXCEPTION_BITMAP in vmx_update_guest_cr() when transitioning from >> real to >>> protected mode. In my codebase, I could fix this trivially by >> clearing the >>> debug_state_latch and letting vmx_do_resume() reapply the setting. >> However, >>> while it looks like a valid issue in the unmodified codebase, I'm not >> sure. So >>> maybe someone might test/examine it and decide if it is real and >> whether some >>> more complex fix is required? >> >> In vmx_update_guest_cr(), where EXCEPTION_BITMAP gets reset after exit >> from >> real mode, try setting v->arch.hvm_vcpu.debug_state_latch=0 and >> raise_softirq(SCHEDULE_SOFTIRQ). >> >> -- Keir >> > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |