On Mon, Oct 27, 2025 at 6:42 PM Sean Christopherson <[email protected]> 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?

