Sean Christopherson 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.
Ah yea.
> 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.
No this name is fine then. I got dyslexic with mode vs type, apologies.
>
> > > #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.
Sounds good.
>
> Or did you mean something else?
No.
Ira
