linux-kernel - Re: [GIT PULL] KVM: x86: Selftests changes for 6.9

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZfDeohmtLXERhyzC@google.com>
Date: Tue, 12 Mar 2024 16:00:50 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] KVM: x86: Selftests changes for 6.9

On Mon, Mar 11, 2024, Paolo Bonzini wrote:
> On 3/8/24 23:36, Sean Christopherson wrote:
> > Add SEV(-ES) smoke tests, and start building out infrastructure to utilize the
> > "core" selftests harness and TAP.  In addition to provide TAP output, using the
> > infrastructure reduces boilerplate code and allows running all testscases in a
> > test, even if a previous testcase fails (compared with today, where a testcase
> > failure is terminal for the entire test).
> 
> Hmm, now I remember why I would have liked to include the AMD SEV changes in
> 6.9 --- because they get rid of the "subtype" case in selftests.
> 
> It's not a huge deal, it's just a nicer API, and anyway I'm not going to ask
> you to rebase on top of my changes; and you couldn't have known that when we
> talked about it last Wednesday, since the patches are for the moment closely
> guarded on my hard drive.

Heh, though it is obvious in hindsight.
 
> But it may still be a good reason to sneak those as well in the second week
> of the 6.9 merge window, though I'm not going to make a fuss if you disagree.

My preference is still to wait.  I would be very surprised if the subtype code
gains any users in the next few weeks, i.e. I doubt it'll be any harder to rip
out the subtype code in 6.9 versus 6.10.

On the other hand, waiting until 6.10 for the SEV changes will give us a bit more
time to see how they interact with the SNP and TDX series, e.g. in the off chance
there's something in the uAPI that could be done better for SNP and/or TDX.