Re: [PATCH v1 1/1] KVM: x86: Merge pending debug causes when vectoring #DB

[Sean Christopherson]

On Thu, May 14, 2026, Sean Christopherson wrote:
> On Thu, May 14, 2026, Sean Christopherson wrote:
> > On Wed, May 13, 2026, Sean Christopherson wrote:
> > > On Wed, Jan 07, 2026, Aidan Khoury wrote:
> > > So while I don't exactly love the idea, I think this?  Compile tested only at
> > > this point, I'll try to properly test it tomorrow.
> > 
> > Confirmed the below works, once I remembered how to configure debug breakpoints.
> > I'll plan on sending a v2 on your behalf, along with a KVM-Unit-Test testcase.
> 
> Ugh, and of course the test fails on AMD.  I'll still send the KVM patch, but
> I'll hold off on the KUT mini-series until I've done at least a little digging
> through the APM (I'm not exactly brimming with confidence that SVM can handle
> this correctly).

Ok, I'm not crazy, AMD SVM simply doesn't support this.  E.g. from an old paper
on making a VMM/hypervisor truly transparent:

  Similarly, native x86 CPUs hold off debug exceptions for a one-instruction
  window following MOV %SS instructions. AMD's SVM provides no information
  about pending debug exceptions if an exit occurs in such a window [2]. We
  constructed a simple SVM detector based on this discrepancy in less than
  100 lines of C and assembly.

The easy solution for the test is to skip it on AMD, but before we do any of this,
why do you care?  I.e. what prompted this patch?  If this is purely an academic
exercise, then no small part of me thinks it might be better for KVM to take an
erratum.  I.e. consistency might be better in this case, maybe?

[*] https://www.usenix.org/legacy/event/hotos07/tech/full_papers/garfinkel/garfinkel_html/paper.html#tex2html2