Re: [Xen-devel] VMI: singlestep event not received

[Mathieu Tarral <mathieu.tarral@xxxxxxxxxxxxxx>]

Le jeudi, avril 25, 2019 9:34 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> a 
écrit :

> On 25/04/2019 00:43, Mathieu Tarral wrote:
>
> > On Wednesday 24 April 2019 14:00, Andrew Cooper andrew.cooper3@xxxxxxxxxx 
> > wrote:
> >
> > > On 23/04/2019 22:59, Mathieu Tarral wrote:
> > >
> > > > > > The funny thing is that it's always at the same instruction that it 
> > > > > > fails, the 106th singlestep,
> > > > > > at 0x806d32dc:
> > > > > > [0x7c90e514]> s 0x806d32dc
> > > > > > [0x806d32dc]> pd 10
> > > > > > 0x806d32dc 890d8000feff mov dword [0xfffe0080], ecx
> > > > > > This is a read of the APIC TPR, which is very commonly an operation
> > > > > > accelerated by hardware (because without it, virtualising windows 
> > > > > > XP is
> > > > > > exceedingly slow).
> > > > > > What is your CPU, and how exactly are you trying to singlestep.  Is 
> > > > > > it
> > > > > > with MTF, or using the trap flag inside the guest?
> > > > > > My CPU is an Intel i7-8750H.
> > > > > > I'm using the libvmi API, which is enabling the MTF flag to 
> > > > > > singlestep, if i judge by the debug logs.
> > > > > > Ok - that is a CoffeeLake.
> > >
> > > I've had a quick play with a simple example (XTF test and xen-access)
> > > and MTF does appear to work fine with both TPR shadowing and full APIC
> > > virtualisation.  I've tried on Haswell, KabyLake and CoffeeLake.
> > > Thank you for testing.
> >
> > > Can you describe the exact VMI configuration you've got enabled -
> > > specifically which other intercepts are active?
> > > My BreakpointManager class is dealing with VMI events.
> > > It registers 3 events:
> >
> > -   int3
> > -   debug event (for hardware breakpoints)
> > -   singlestep event (for breakpoint recoil on int3)
> >
> > https://github.com/Wenzel/pyvmidbg/blob/1a2e97c238a96c98c19cdbbdefa6047be246e504/vmidbg/breakpoint.py#L20
>
> What about control register intercepts, or memory permission restrictions?

I'm not using them, not CR3 intercepts, or mem_events registered.

> I expect things are going wrong when the TPR access is emulated by Xen,
> rather than completed directly by hardware, but I can't explain how
> you'd be getting into that situation without some other VMI settings
> being active at the same time.
I don't really know Xen, so I' can't explain it myself.
How can I debug this ?
Do you want me to add a printk somewhere ?

Mathieu



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