|
[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
Juergen Gross wrote on 2014-05-06:
> Hi folks,
>
> any chance to get this fixed?
Hi Juegen,
I am really sorry that I have forgotten to do this. I am too busy on other task
recently. :(
I will provide a patch ASAP.
>
>
> Juergen
>
> On 07.03.2014 06:10, Zhang, Yang Z wrote:
>> Jan Beulich wrote on 2014-03-05:
>>>>>> 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,
>>>>> 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?
>>>
>>> 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.
>>
>> Oh, I am sorry, I misunderstand you. How about the following changes:
>> Intercept the TRAP_debug when schedule out and drop it after restoring
>> VCPU's DR register into hardware.
>>
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index b128e81..5784dd1 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -372,6 +372,10 @@ static void vmx_save_dr(struct vcpu *v)
>> v->arch.hvm_vmx.exec_control |= CPU_BASED_MOV_DR_EXITING;
>> vmx_update_cpu_exec_control(v);
>> + /* Trap debug for signle stepping. */
>> + v->arch.hvm_vmx.exception_bitmap |= 1 << TRAP_debug;
>> + vmx_update_exception_bitmap(v);
>> +
>> v->arch.debugreg[0] = read_debugreg(0);
>> v->arch.debugreg[1] = read_debugreg(1);
>> v->arch.debugreg[2] = read_debugreg(2); @@ -388,6 +392,13 @@
>> static void __restore_debug_registers(struct vcpu *v)
>>
>> v->arch.hvm_vcpu.flag_dr_dirty = 1;
>> + /*
>> + * After restore, hardware has the right context.
>> + * So no need to trap debug anymore.
>> + */
>> + v->arch.hvm_vmx.exception_bitmap |= ~(1 << TRAP_debug);
>> + vmx_update_exception_bitmap(v);
>> +
>> write_debugreg(0, v->arch.debugreg[0]); write_debugreg(1,
>> v->arch.debugreg[1]); write_debugreg(2, v->arch.debugreg[2]); @@
>> -1171,8 +1182,6 @@ void vmx_update_debug_state(struct vcpu *v)
>> unsigned long mask;
>>
>> mask = 1u << TRAP_int3;
>> - if ( !cpu_has_monitor_trap_flag )
>> - mask |= 1u << TRAP_debug;
>>
>> if ( v->arch.hvm_vcpu.debug_state_latch )
>> v->arch.hvm_vmx.exception_bitmap |= mask; @@ -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; + 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)); +
>> hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE); +
>> }
>> break;
>> case TRAP_int3:
>> {
>> diff --git a/xen/include/asm-x86/hvm/hvm.h
>> b/xen/include/asm-x86/hvm/hvm.h index dcc3483..0d76d8c 100644
>> --- a/xen/include/asm-x86/hvm/hvm.h
>> +++ b/xen/include/asm-x86/hvm/hvm.h
>> @@ -378,7 +378,8 @@ static inline int hvm_event_pending(struct vcpu *v)
>> (cpu_has_xsave ? X86_CR4_OSXSAVE : 0))))
>> /* These exceptions must always be intercepted. */ -#define
>> HVM_TRAP_MASK ((1U << TRAP_machine_check) | (1U << TRAP_invalid_op))
>> +#define HVM_TRAP_MASK ((1U << TRAP_machine_check) | (1U <<
>> TRAP_invalid_op) |\ + (1U << TRAP_debug))
>>
>> /*
>> * x86 event types. This enumeration is valid for:
>>
>>
>> Best regards,
>> Yang
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxx
>> http://lists.xen.org/xen-devel
>>
>>
>
>
Best regards,
Yang
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |