Re: Multiplexing RFLAGS.TF

[Avi Kivity <avi@redhat.com>]

  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.