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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.03.14 at 03:10, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
> Jan Beulich wrote on 2014-03-07:
>>>>> On 07.03.14 at 06:10, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
>>> @@ -2689,10 +2698,18 @@ 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(); +            exit_qualification |=
>>> 0xffff0ff0;
>> 
>> Is this really needed?
> 
> Yes. The reserved bits need to set to 1 in DB6. But it is cleared in 
> exit_qualification.

In which case I'd strongly suggest adding a respective #define to
debugreg.h and using it here.

>>> +            if ( v->domain->debugger_attached )
>>> +            {
>>> +                write_debugreg(6, exit_qualification);
>>> +                domain_pause_for_debugger();
>>> +            }
>>> +            else
>>> +            {
>>> +                __restore_debug_registers(v);
>>> +                write_debugreg(6, exit_qualification |
>> read_debugreg(6));
>> 
>> I still wonder whether it wouldn't be more efficient to simply or
>> exit_qualification into v->arch.debugreg[6] before calling
>> __restore_debug_registers().
>> 
> 
> __restore_debug_registers() only copy the v->arch.debugreg[6] into hardware 
> DB6 when flag_dr_dirty is cleared. So as I mentioned before, the hardware DB 
> register will hold the latest value if flag_dr_dirty is set and we should 
> write hardware DB6 directly.

Except that, as per the earlier discussion, the intercept should not
occur when flag_dr_dirty is set, as it ought to have got disabled
when setting the flag while restoring debug registers.

Jan


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