On 08/02/2010 04:17 AM, Jan Kiszka wrote:
So we need an rflags_guest_owned_bits, usually set to -1ULL, but
sometimes (NMI, host debugging) clearing EFLAGS_TF. When we do that, we
need to intercept instructions that influence RFLAGS.TF (POPF, IRET,
INTn) and emulate them. Otherwise, the guest can disable tracing which
was enabled on behalf of the host.
I was still waiting on some smart idea from AMD how to properly
implement NMIs without having to fully emulate IRET. Probably there is
no alternative...
Well, there's the existing singlestep implementation, it just needs to
be fixed not to assume the host has exclusive ownership of TF. It's
probably faster than emulation, and certainly more accurate.
We also need to drop the 'return 1' on the top of the function to allow
both guest and host tracing.
Support for host and guest-initiated tracing at the same time would be
nice, but I would not spend to much effort on this corner case of the
corner cases. If it happens to fall off from the NMI fix, OK. But
otherwise let the host rule TF if it wants to.
Taking an NMI while the guest is tracing itself is not a corner case. I
agree about simulataneous debugging.
On Intel, the situation is harder. We can't trap POPF or IRET. What we
can do, is use the Monitor Trap Flag on hosts that have it.
Actually, I think a POPF or IRET that disables TF still takes a last
trap? If so it's workable.
Setting TF before POPF and IRET should give us at least the chance to
provide host-overrules-guest tracing support. Adding monitor trap
support would be nice. It would allow more things actually, but it may
then require some additional knob in the user/kernel interface to
control the mode (MTF steps into exceptions/interrupts, TF not).
There's also branch trace in debugctlmsr, that allows you to quickly
step out of a function.
Comments? Perhaps I missed something. Maybe I'll try writing a test
case to prove the brokenness, it's fashionable these days.
Jan, as this is your code, are you interested in doing this?
I'm not very keen on writing complex and error-prone opcode emulations,
but in principle resolving the AMD issue is on my long to-do list - with
moderate prio though.
Definitely all this code has to be accompanied by test cases.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
