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

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

>>> On 05.03.14 at 03:22, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
> 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,
>>>>>      }
>>>> 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?

It certainly shouldn't when single stepping. And as long as the guest
clears the bit while handling the single step trap, it won't see it set on
other kinds of #DB. After all that's how hardware behaves.

>> 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.

Oh, perhaps you misunderstood then: I didn't suggest to always
set that flag. What I suggested is that during the intercepted
TRAP_debug we should or exit_qualification (which ought to
have BS set when single stepping with no other breakpoint
enabled in DR7) into the in-memory copy of DR6. Once the
intercept got dropped (as also suggested), hardware would again
take care of setting DR6 correctly.


Xen-devel mailing list



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