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? So far I''m emulating PUSHF/POPF to hide the hypervisor''s trap flag, and eventually I''ll multiplex it down to the guest, but I''m having issues. 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. I''m mainly running into problems with interrupts (I believe). I think during a context switch from a timer, I''m doing things like enabling the trap flag on CR3 change. The guest seems to get caught in a loop somewhere in kernel land after stepping is disabled. Any thoughts on the general idea, or hints in the right direction would be appreciated. Thanks! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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 flagHow 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.
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@xen.org> 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. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel