Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 7 Jul 2022 17:14:40 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     Jim Mattson <jmattson@google.com>
Cc:     Paolo Bonzini <pbonzini@redhat.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Joerg Roedel <joro@8bytes.org>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, Oliver Upton <oupton@google.com>,
        Peter Shier <pshier@google.com>
Subject: Re: [PATCH v2 05/21] KVM: nVMX: Prioritize TSS T-flag #DBs over
 Monitor Trap Flag
Message-ID: <YscUgGElDEPIkIEo@google.com>
References: <20220614204730.3359543-1-seanjc@google.com>
 <20220614204730.3359543-6-seanjc@google.com>
 <CALMp9eSH1O8keAVxZzfdvV1vu0AJBhaXVUfkSgYgCPOoSB5=Jw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALMp9eSH1O8keAVxZzfdvV1vu0AJBhaXVUfkSgYgCPOoSB5=Jw@mail.gmail.com>
Precedence: bulk

On Wed, Jul 06, 2022, Jim Mattson wrote:
> On Tue, Jun 14, 2022 at 1:47 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > Service TSS T-flag #DBs prior to pending MTFs, as such #DBs are higher
> > priority than MTF.  KVM itself doesn't emulate TSS #DBs, and any such
> 
> Is there a KVM erratum for that?

Nope, just this hilarious TODO:

	/*
	 * TODO: What about debug traps on tss switch?
	 *       Are we supposed to inject them and update dr6?
	 */

> > exceptions injected from L1 will be handled by hardware (or morphed to
> > a fault-like exception if injection fails), but theoretically userspace
> > could pend a TSS T-flag #DB in conjunction with a pending MTF.
> >
> > Note, there's no known use case this fixes, it's purely to be technically
> > correct with respect to Intel's SDM.
> 
> A test would be nice. :-)

LOL, yeah, but ensuring userspace-injected TSS T-bit #DBs work isn't exactly on
my list of top 100 things to look at.