[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting


  • To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • From: "Byrne, John (HP Labs)" <john.l.byrne@xxxxxx>
  • Date: Mon, 11 May 2009 17:21:56 +0000
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 11 May 2009 10:22:39 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcnR8XOAYOeTv7J5Qqms8GGZVbPMcQAE5g3CABNJI2AAAnC5WQAABxig
  • Thread-topic: [Xen-devel] vmx_update_guest_cr() losing EXCEPTION_BITMAP setting

I had hit upon the fix of clearing v->arch.hvm_vcpu.debug_state_latch=0 and 
this had apparently fixed the problem I was seeing. However, reviewing the 
code, the schedule_softirq(SECHDULE_SOFTIRQ) you added looks necessary for a 
complete fix. A caveat: I am not running a domain-debugger, I am just borrowing 
the code for my lockstep work. I don't see why the fix wouldn't work in that 
case, but I'm not testing it.

John


> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Monday, May 11, 2009 10:15 AM
> To: Byrne, John (HP Labs)
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.