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

Re: [Xen-devel] Debug-Registers in HVM domain destroyed

>>> On 14.02.14 at 13:18, Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> wrote:
> On 14.02.2014 11:40, Jan Beulich wrote:
>>>>> On 14.02.14 at 10:33, Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> wrote:
>>> Debug registers are restored on vcpu switch only if db7 has any debug events
>>> activated. This leads to problems in the following cases:
>>> - db0-3 are changed by the guest before events are set "active" in db7. In 
> case
>>>     of a vcpu switch between setting db0-3 and db7, db0-3 are lost. BTW: 
> setting
>>>     db7 before db0-3 is no option, as this could trigger debug interrupts 
>>> due 
> to
>>>     stale db0-3 contents.
>>> - single stepping is used and vcpu switch occurs between the single step 
>>> trap
>>>     and reading of db6 in the guest. db6 contents (single step indicator) 
> are
>>>     lost in this case.
>> Not exactly, at least not looking at how things are supposed to work:
>> __restore_debug_registers() gets called when
>> - context switching in (vmx_restore_dr())
>> - injecting TRAP_debug
> Is this the case when the guest itself uses single stepping? Initially the
> debug trap shouldn't cause a VMEXIT, I think.

That looks like a bug, indeed - it's missing from the initially set
exception_bitmap. Could you check whether adding this in
construct_vmcs() addresses that part of the issue? (A proper fix
would likely include further adjustments to the setting of this flag,
e.g. clearing it alongside clearing the DR intercept.) But then
again all of this already depends on cpu_has_monitor_trap_flag -
if that's set on your system, maybe you could try suppressing its
detection (by removing CPU_BASED_MONITOR_TRAP_FLAG from
the optional feature set in vmx_init_vmcs_config())?

> And I'm not sure the 
> hypervisor will see a guest setting TF via an IRET.

It shouldn't need to know of this.


Xen-devel mailing list



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