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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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
- any DRn is being accessed

So when your guest writes DR[0-3], debug registers should get
restored (from their original zero values) and the guest would be
permitted direct access to the hardware registers. Once context
switched out, vmx_save_dr() ought to be saving the values
(irrespective of DR7 contents, only depending upon
v->arch.hvm_vcpu.flag_dr_dirty). During the next context
switch in, they would get restored immediately if DR7 already has
some breakpoint enabled, or again during first DR access if not.

Hence I think that in general this ought to work. Question is
whether one of the more modern feature additions broke any of
this. Assuming that your guest isn't doing heavy accesses to the
debug registers, instrumenting the hypervisor side code to track
the saving/restoring shouldn't be causing too much log output (as
long as you suppress output from the context switch path when
no relevant state changed).

Jan


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