Re: [Xen-devel] Single step in HVM domU on Intel machine may see wrong DB6

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Jan Beulich wrote on 2014-02-27:
>>>> On 27.02.14 at 02:31, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
>> Jan Beulich wrote on 2014-02-27:
>>>>>> On 26.02.14 at 06:15, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>
> wrote:
>>>> @@ -2690,9 +2688,13 @@ void vmx_vmexit_handler(struct
> cpu_user_regs
>>> *regs)
>>>>              __vmread(EXIT_QUALIFICATION, &exit_qualification);
>>>>              HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
>>>>              write_debugreg(6, exit_qualification | 0xffff0ff0);
>>>> -            if ( !v->domain->debugger_attached ||
>>>> cpu_has_monitor_trap_flag ) -                goto exit_and_crash; -
>>>>        domain_pause_for_debugger(); +            if (
>>>> v->domain->debugger_attached ) +
>>>> domain_pause_for_debugger(); +            else +            { +
>>>>        __restore_debug_registers(v); +
>>>> hvm_inject_hw_exception(TRAP_debug,
> HVM_DELIVER_NO_ERROR_CODE); +
>>>>      }
>>> 
>>> I suppose you need to set DR6.BS after restoring the reigsters?
>> 
>> Right but is not enough. If flag_dr_dirty is set, we need to restore
>> register from hardware. Conversely, restore is from debugreg and set
>> DR6 to exit_qualification.
> 
> After some more thought, I in fact doubt that restoring the debug
> registers is in line with the current model: We should simply set
> DR6.BS in the in-memory copy when the debug registers aren't live yet
> (and it doesn't hurt to always do that). And since DR6 bits generally
> are sticky, I think exit_qualification actually needs to be or-ed into the 
> in-memory copy.

Will guest be confused to see the DR6.BS always set?

> 
> And presumably we would be better off if we dropped the interception
> of TRAP_debug once we restored the debug registers.

Yes, it's unnecessary to trap into hypervisor always. Also, if we set DR6.BS 
always, I guess there is no need to intercept the TRAP_debug.

> 
> Jan


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel