linux-kernel - Re: [PATCH v11 21/21] KVM: selftests: Add TDX lifecycle test

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: <CAAhR5DGAOsv-SiLkCziazy4Q9qG_iNqn5Zb9ik+KQ63KDzJsAA@mail.gmail.com>
Date: Mon, 27 Oct 2025 19:53:09 -0500
From: Sagi Shahar <sagis@...gle.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Ira Weiny <ira.weiny@...el.com>, linux-kselftest@...r.kernel.org, 
	Paolo Bonzini <pbonzini@...hat.com>, Shuah Khan <shuah@...nel.org>, 
	Ackerley Tng <ackerleytng@...gle.com>, Ryan Afranji <afranji@...gle.com>, 
	Andrew Jones <ajones@...tanamicro.com>, Isaku Yamahata <isaku.yamahata@...el.com>, 
	Erdem Aktas <erdemaktas@...gle.com>, Rick Edgecombe <rick.p.edgecombe@...el.com>, 
	Roger Wang <runanwang@...gle.com>, Binbin Wu <binbin.wu@...ux.intel.com>, 
	Oliver Upton <oliver.upton@...ux.dev>, "Pratik R. Sampat" <pratikrajesh.sampat@....com>, 
	Reinette Chatre <reinette.chatre@...el.com>, Chao Gao <chao.gao@...el.com>, 
	Chenyi Qiang <chenyi.qiang@...el.com>, linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v11 21/21] KVM: selftests: Add TDX lifecycle test

On Mon, Oct 27, 2025 at 6:42 PM Sean Christopherson <seanjc@...gle.com> wrote:
>
> On Mon, Oct 27, 2025, Ira Weiny wrote:
> > Sean Christopherson wrote:
> > > diff --git a/tools/testing/selftests/kvm/include/kvm_util.h b/tools/testing/selftests/kvm/include/kvm_util.h
> > > index af52cd938b50..af0b53987c06 100644
> > > --- a/tools/testing/selftests/kvm/include/kvm_util.h
> > > +++ b/tools/testing/selftests/kvm/include/kvm_util.h
> > > @@ -210,6 +210,20 @@ kvm_static_assert(sizeof(struct vm_shape) == sizeof(uint64_t));
> > >     shape;                                  \
> > >  })
> > >
> > > +#define __VM_TYPE(__mode, __type)          \
> > > +({                                         \
> > > +   struct vm_shape shape = {               \
> > > +           .mode = (__mode),               \
> > > +           .type = (__type)                \
> > > +   };                                      \
> > > +                                           \
> > > +   shape;                                  \
> > > +})
> > > +
> > > +#define VM_TYPE(__type)                            \
> > > +   __VM_TYPE(VM_MODE_DEFAULT, __type)
> >
> > We already have VM_SHAPE()?  Why do we need this as well?
>
> VM_SHAPE() takes the "mode", and assumes a default type.  The alternative would
> be something like __VM_SHAPE(__type, __mode), but that's annoying, especially on
> x86 which only has one mode.
>
> And __VM_SHAPE(__type) + ____VM_SHAPE(__type, __mode) feels even more weird.
>
> I'm definitely open to more ideas, VM_TYPE() isn't great either, just the least
> awful option I came up with.
>
> > >  #if defined(__aarch64__)
> > >
> > >  extern enum vm_guest_mode vm_mode_default;
> > > diff --git a/tools/testing/selftests/kvm/include/x86/processor.h b/tools/testing/selftests/kvm/include/x86/processor.h
> > > index 51cd84b9ca66..dd21e11e1908 100644
> > > --- a/tools/testing/selftests/kvm/include/x86/processor.h
> > > +++ b/tools/testing/selftests/kvm/include/x86/processor.h
> > > @@ -362,6 +362,10 @@ static inline unsigned int x86_model(unsigned int eax)
> > >     return ((eax >> 12) & 0xf0) | ((eax >> 4) & 0x0f);
> > >  }
> > >
> > > +#define VM_SHAPE_SEV               VM_TYPE(KVM_X86_SEV_VM)
> > > +#define VM_SHAPE_SEV_ES            VM_TYPE(KVM_X86_SEV_ES_VM)
> > > +#define VM_SHAPE_SNP               VM_TYPE(KVM_X86_SNP_VM)
> >
> > FWIW I think the SEV bits should be pulled apart from the TDX bits and the
> > TDX bits squashed back into this series with the SEV as a per-cursor patch.
>
> Ya, that's my intent, "officially" post and land this SEV+ change, then have the
> TDX series build on top.  Or did you mean something else?

I've got v12 mostly ready to be sent for review. I was thinking of
incorporating this change as part of that series. Do you prefer that I
wait until this patch lands before I post v12?