Multiplexing RFLAGS.TF

[Avi Kivity <avi@redhat.com>]

  static int db_interception(struct vcpu_svm *svm)
{
     struct kvm_run *kvm_run = svm->vcpu.run;

     if (!(svm->vcpu.guest_debug &
           (KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP)) &&
         !svm->nmi_singlestep) {
         kvm_queue_exception(&svm->vcpu, DB_VECTOR);
         return 1;
     }

     if (svm->nmi_singlestep) {
         svm->nmi_singlestep = false;
         if (!(svm->vcpu.guest_debug & KVM_GUESTDBG_SINGLESTEP))
             svm->vmcb->save.rflags &=
                 ~(X86_EFLAGS_TF | X86_EFLAGS_RF);
         update_db_intercept(&svm->vcpu);
     }

This code assumes that either the guest is debugging itself, or 
(nmi_singlestep | guest debugging).  However if the guest is debugging 
itself and takes an NMI, or if both host and guest are debugging the 
guest, things will go wrong.

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.

We also need to drop the 'return 1' on the top of the function to allow 
both guest and host tracing.

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.

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?

Sheng, the Intel bits?

-- 
error compiling committee.c: too many arguments to function