Xen project Mailing List

When I intercept a TRAP_debug (and dr6 indicates it was because of the trap flag), I can disassemble the bytes at RIP to figure out what's going on.

Any instruction that modifies RFLAGS can be emulated with varying degrees of easy using Xen's emulate code (and some additions) as though the trap flag were disabled.

I think where I'm going wrong is event delivery. I'm thinking now that I'd have to intercept every type of exception, and somehow also intercept IRQs and anything else that delivers an interrupt. Or maybe I could breakpoint every interrupt handler somehow and fix the RFLAGS value that was pushed on the stack.

I guess I'm just looking for input on the Right Way (TM) to do it, if there even is one.

Thanks!

On Thu, May 2, 2013 at 7:45 AM, Tim Deegan <tim@xxxxxxx> wrote:

At 23:10 -0400 on 30 Apr (1367363415), Cutter 409 wrote:
> Hi all,
>
> Does anyone have thoughts on extending v->arch.hvm_vcpu.single_step to
> support pre-MTF systems, in a way that would mimic the MTF?

It sounds hard. :P

> So far I'm emulating PUSHF/POPF to hide the hypervisor's trap flag

How are you doing that? Are you also catching SMSW/LMSW, and other ways
that RFLAGS can be accessed (interrupt delivery, system call, IRET,
task switching &c)?

> Right now, I'm enabling X86_EFLAGS_TF in vmx_intr_assist, just like where
> MTF is enabled if desired. It's cleared at the start of vmx_exit_handler
> (if required). I'm catching single step from TRAP_debug, but when I disable
> stepping the guest usually seems to hang. It's not completely frozen,
> because if I turn single stepping back on I see more events, and the
> instruction pointer is moving.

Well it sounds like you've probably set TF when you want it set, so I
assume that the OS has
- seen that TS is set and got confused;
- accidentally turned TS on (e.g. in an IRET) and hung taking #DB; or
- tried to turn on TF itself and you've turned it off in a vmexit. :)

TBH, given the number of ways RFLAGS can be read and written in the
guest, trying to shadow it like this seems like a _lot_ of work.

Tim.

Re: [Xen-devel] EFLAGS based v->arch.hvm_vcpu.single_step