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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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