Re: [Xen-devel] [PATCH 00/11] Fixes to debugging facilities

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 06/04/2018 06:39 PM, Andrew Cooper wrote:
> On 04/06/18 14:59, Andrew Cooper wrote:
>> So this started as a small fix for the vmentry failure (penultimate patch),
>> and has snowballed...
>>
>> I'm fairly confident that everything involving DEBUGCTL.BTF is broken, and
>> there are definitely bugs with configuring DEBUGCTL.RTM (which really isn't
>> helped by the fact that the GCC TSX intrinsics render the resulting code
>> un-debuggable.)  I'll defer fixing these swamps for now.
>>
>> The first 4 patches probably want backporting to the stable trees, so I've
>> taken care to move them ahead of patch 6 for backport reasons.  While all
>> fixes would ideally be backported, I can't find a way of fixing %dr6 merging
>> (as it needs to be done precicely once) without a behavioural change in the
>> monitor subsystem.
>>
>> Patch 8 probably breaks introspection, so can't be taken at this point.  See
>> that patch for discussion of the problem and my best guess at a solution.
> 
> As spotted by Razvan, I forgot to mention that this series is built on
> top of "x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit".  It can be
> found in git form here:
> 
> http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/debug-fixes-v1

FWIW, you're exactly right about the recursive injection vm_events. I've
tested this with xen-access and the test-hvm64-swint-emulation XTF test:

1. xl create xl create -p ./test-hvm64-swint-emulation.cfg
2. xen-access <DOMID> breakpoint
3. xl unpause <DOMID>

The test domain will not be able to finish until xen-access is stopped
(with ^C).

So this does indeed break introspection the way it is now implemented.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel