Re: [kvm-unit-tests GIT PULL] x86: random smattering of changes

[Yosry Ahmed]

On Thu, May 28, 2026 at 1:04 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Thu, May 28, 2026, Yosry Ahmed wrote:
> > On Thu, May 28, 2026 at 12:07 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > >
> > > On Wed, May 27, 2026, Yosry Ahmed wrote:
> > > > > > ----------------------------------------------------------------
> > > > > > Isaku Yamahata (2):
> > > > > >       x86: Replace NOP with CPUID after WRMSR(TSCDEADLINE) to serialize deadline timer
> > > > > >       x86: tscdeadline_latency: Remove unnecessary nop
> > > > > >
> > > > > > Jim Mattson (1):
> > > > > >       x86: nVMX: Add retry loop to advanced RTM debugging subtest
> > > > > >
> > > > > > Kevin Cheng (2):
> > > > > >       x86/svm: Add missing svm intercepts
> > > > > >       x86/svm: Add unsupported instruction intercept test
> > > > >
> > > > > Any reason not to include this series:
> > > > > https://lore.kernel.org/kvm/20260312200308.3089379-1-chengkev@xxxxxxxxxx/?
> > >
> > > I ran out of steam (and time), and I don't want to merge like this without a high
> > > level of confidence that it's the least awful option.
> >
> > We're already doing this for vmx:
> > https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/blob/master/x86/vmx_tests.c?ref_type=heads#L806.
> >
> > If this is the only thing holding that series, I think cleaning it up
> > should be done separately for both VMX and SVM.
>
> I don't buy that argument.  Taking it to the extreme, that's like saying it's ok
> to use bare "unsigned" because there exists such code in the kernel.  It's very
> difficult to make progress if we don't raise the bar.

That's fair.

> I'm not saying "no" to the series, nor am saying you (or Kevin) needs to clean
> up the nVMX code in order to land the nSVM code.  I'm simply explaining why I
> didn't grab the series: it's got some fugly code I want to look at more closely,
> but I ran out of time and brainpower.

Understandable, sorry if I came off too pushy. Thank you for taking
the time to shepherd x86 KUT changes.