This is v8 of the TDX selftests.

This series is based on v6.16

Aside from a rebase, this version includes a minor bug fix for
"KVM: selftests: Update kvm_init_vm_address_properties() for TDX" which
was called out in v6 by Ira Weiny.

Thanks,

Changes from v7:
- Rebased on top of v6.16
- Minor build error fix

Ackerley Tng (12):
  KVM: selftests: Add function to allow one-to-one GVA to GPA mappings
  KVM: selftests: Expose function that sets up sregs based on VM's mode
  KVM: selftests: Store initial stack address in struct kvm_vcpu
  KVM: selftests: Add vCPU descriptor table initialization utility
  KVM: selftests: TDX: Use KVM_TDX_CAPABILITIES to validate TDs'
    attribute configuration
  KVM: selftests: TDX: Update load_td_memory_region() for VM memory
    backed by guest memfd
  KVM: selftests: Add functions to allow mapping as shared
  KVM: selftests: KVM: selftests: Expose new vm_vaddr_alloc_private()
  KVM: selftests: TDX: Add support for TDG.MEM.PAGE.ACCEPT
  KVM: selftests: TDX: Add support for TDG.VP.VEINFO.GET
  KVM: selftests: TDX: Add TDX UPM selftest
  KVM: selftests: TDX: Add TDX UPM selftests for implicit conversion

Erdem Aktas (3):
  KVM: selftests: Add helper functions to create TDX VMs
  KVM: selftests: TDX: Add TDX lifecycle test
  KVM: selftests: TDX: Add TDX HLT exit test

Isaku Yamahata (1):
  KVM: selftests: Update kvm_init_vm_address_properties() for TDX

Roger Wang (1):
  KVM: selftests: TDX: Add TDG.VP.INFO test

Ryan Afranji (2):
  KVM: selftests: TDX: Verify the behavior when host consumes a TD
    private memory
  KVM: selftests: TDX: Add shared memory test

Sagi Shahar (10):
  KVM: selftests: TDX: Add report_fatal_error test
  KVM: selftests: TDX: Adding test case for TDX port IO
  KVM: selftests: TDX: Add basic TDX CPUID test
  KVM: selftests: TDX: Add basic TDG.VP.VMCALL<GetTdVmCallInfo> test
  KVM: selftests: TDX: Add TDX IO writes test
  KVM: selftests: TDX: Add TDX IO reads test
  KVM: selftests: TDX: Add TDX MSR read/write tests
  KVM: selftests: TDX: Add TDX MMIO reads test
  KVM: selftests: TDX: Add TDX MMIO writes test
  KVM: selftests: TDX: Add TDX CPUID TDVMCALL test

Yan Zhao (1):
  KVM: selftests: TDX: Test LOG_DIRTY_PAGES flag to a non-GUEST_MEMFD
    memslot

 tools/testing/selftests/kvm/Makefile.kvm      |    8 +
 .../testing/selftests/kvm/include/kvm_util.h  |   36 +
 .../selftests/kvm/include/x86/kvm_util_arch.h |    1 +
 .../selftests/kvm/include/x86/processor.h     |    2 +
 .../selftests/kvm/include/x86/tdx/td_boot.h   |   83 ++
 .../kvm/include/x86/tdx/td_boot_asm.h         |   16 +
 .../selftests/kvm/include/x86/tdx/tdcall.h    |   54 +
 .../selftests/kvm/include/x86/tdx/tdx.h       |   67 +
 .../selftests/kvm/include/x86/tdx/tdx_util.h  |   23 +
 .../selftests/kvm/include/x86/tdx/test_util.h |  133 ++
 tools/testing/selftests/kvm/lib/kvm_util.c    |   74 +-
 .../testing/selftests/kvm/lib/x86/processor.c |   97 +-
 .../selftests/kvm/lib/x86/tdx/td_boot.S       |  100 ++
 .../selftests/kvm/lib/x86/tdx/tdcall.S        |  163 +++
 tools/testing/selftests/kvm/lib/x86/tdx/tdx.c |  243 ++++
 .../selftests/kvm/lib/x86/tdx/tdx_util.c      |  643 +++++++++
 .../selftests/kvm/lib/x86/tdx/test_util.c     |  187 +++
 .../selftests/kvm/x86/tdx_shared_mem_test.c   |  129 ++
 .../testing/selftests/kvm/x86/tdx_upm_test.c  |  461 ++++++
 tools/testing/selftests/kvm/x86/tdx_vm_test.c | 1254 +++++++++++++++++
 20 files changed, 3734 insertions(+), 40 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/include/x86/tdx/td_boot.h
 create mode 100644 tools/testing/selftests/kvm/include/x86/tdx/td_boot_asm.h
 create mode 100644 tools/testing/selftests/kvm/include/x86/tdx/tdcall.h
 create mode 100644 tools/testing/selftests/kvm/include/x86/tdx/tdx.h
 create mode 100644 tools/testing/selftests/kvm/include/x86/tdx/tdx_util.h
 create mode 100644 tools/testing/selftests/kvm/include/x86/tdx/test_util.h
 create mode 100644 tools/testing/selftests/kvm/lib/x86/tdx/td_boot.S
 create mode 100644 tools/testing/selftests/kvm/lib/x86/tdx/tdcall.S
 create mode 100644 tools/testing/selftests/kvm/lib/x86/tdx/tdx.c
 create mode 100644 tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c
 create mode 100644 tools/testing/selftests/kvm/lib/x86/tdx/test_util.c
 create mode 100644 tools/testing/selftests/kvm/x86/tdx_shared_mem_test.c
 create mode 100644 tools/testing/selftests/kvm/x86/tdx_upm_test.c
 create mode 100644 tools/testing/selftests/kvm/x86/tdx_vm_test.c

-- 
2.51.0.rc0.155.g4a0f42376b-goog

On Thu, Aug 07, 2025, Sagi Shahar wrote:
> This is v8 of the TDX selftests.
> 
> This series is based on v6.16
> 
> Aside from a rebase, this version includes a minor bug fix for
> "KVM: selftests: Update kvm_init_vm_address_properties() for TDX" which
> was called out in v6 by Ira Weiny.

Folks, this series is completely unacceptable.  Please read through
Documentation/process/maintainer-kvm-x86.rst and fix the myriad issues with this
series.

I will provide detailed feedback on this version to help move things along, but
if v9 doesn't show a marked improvment, don't expect much more than a formletter
response.  I have made my expectations for KVM x86 abundantly clear.

Process violations aside, I am also extremely frustrated that seemingly no effort
has been made to update and polish this series for upstream inclusion.  As Ira
pointed out, there are references to terminology that we haven't used in *years*.

 : If guest memory is backed by restricted memfd
 : 
 : + UPM is being used, hence encrypted memory region has to be
 :   registered
 : + Can avoid making a copy of guest memory before getting TDX to
 :   initialize the memory region

And then there's code like this

 +#define KVM_MAX_CPUID_ENTRIES 256
 +
 +#define CPUID_EXT_VMX                  BIT(5)
 +#define CPUID_EXT_SMX                  BIT(6)
 +#define CPUID_PSE36                    BIT(17)
 +#define CPUID_7_0_EBX_TSC_ADJUST       BIT(1)
 +#define CPUID_7_0_EBX_SGX              BIT(2)
 +#define CPUID_7_0_EBX_INTEL_PT         BIT(25)
 +#define CPUID_7_0_ECX_SGX_LC           BIT(30)
 +#define CPUID_APM_INVTSC               BIT(8)
 +#define CPUID_8000_0008_EBX_WBNOINVD   BIT(9)
 +#define CPUID_EXT_PDCM                 BIT(15)

which is just... ugh.

Please make cleaning up this mess the highest priority for TDX upstreaming.  I
am _thrilled_ (honestly) at the amount test coverage that has been developed for
TDX.  But I am equally angry that so much effort is being put into newfangled
TDX features, and that so little effort is being put into helping review and
polish this series.  I refuse to believe that I am the only person that could
look at the above code and come to the conclusion that it's simply unnacceptable.

Y'all _know_ I am stretched thin, please help distribute the load.

On Mon, 2025-08-11 at 10:38 -0700, Sean Christopherson wrote:
> Please make cleaning up this mess the highest priority for TDX upstreaming.  I
> am _thrilled_ (honestly) at the amount test coverage that has been developed for
> TDX.  But I am equally angry that so much effort is being put into newfangled
> TDX features, and that so little effort is being put into helping review and
> polish this series.  I refuse to believe that I am the only person that could
> look at the above code and come to the conclusion that it's simply unnacceptable.

We were talking about this internally. Behind the scenes Reinette had actually
spent a pretty large amount of time (the majority?) cleaning this series up
actually, to even this level. This was some code cleanup, but also functional
stuff like rooting out bugs where tests would give false positive passes. But
the plan of action was to have some other TDX developers start reviewing it on
the Intel side. I was also wondering how much time Sagi has to spend on it for
follow on versions? We might want to think about a more direct process for
changes->posting depending on if Sagi is able to spend more time.

But Sean, if you want to save some time I think we can just accelerate this
other reviewing. As far as new-fangled features, having this upstream is
important even for that, because we are currently having to keep these tests
plus follow on tests in sync across various development branches. So yea, it's
time to get this over the line.

On Mon, Aug 11, 2025, Rick P Edgecombe wrote:
> But Sean, if you want to save some time I think we can just accelerate this
> other reviewing. As far as new-fangled features, having this upstream is
> important even for that, because we are currently having to keep these tests
> plus follow on tests in sync across various development branches. So yea, it's
> time to get this over the line.

Yes please.  The unspoken threat in my response is that at some point I will just
start NAKing KVM TDX patches :-D

On Mon, Aug 11, 2025 at 3:53 PM Sean Christopherson <seanjc@google.com> wrote:
>
> On Mon, Aug 11, 2025, Rick P Edgecombe wrote:
> > But Sean, if you want to save some time I think we can just accelerate this
> > other reviewing. As far as new-fangled features, having this upstream is
> > important even for that, because we are currently having to keep these tests
> > plus follow on tests in sync across various development branches. So yea, it's
> > time to get this over the line.
>
> Yes please.  The unspoken threat in my response is that at some point I will just
> start NAKing KVM TDX patches :-D

I'm making good progress and the massive refactor is mostly complete.
I believe I should have the patches ready to review next week.

I'm also thinking that it would be easier if I split the series in 2
or possibly 3 patchset. The first one including the setup code and the
basic lifecycle test and then the rest of the tests with possibly the
guest_memfd tests in a separate series. What do you think?

On Thu, Aug 14, 2025, Sagi Shahar wrote:
> On Mon, Aug 11, 2025 at 3:53 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Mon, Aug 11, 2025, Rick P Edgecombe wrote:
> > > But Sean, if you want to save some time I think we can just accelerate this
> > > other reviewing. As far as new-fangled features, having this upstream is
> > > important even for that, because we are currently having to keep these tests
> > > plus follow on tests in sync across various development branches. So yea, it's
> > > time to get this over the line.
> >
> > Yes please.  The unspoken threat in my response is that at some point I will just
> > start NAKing KVM TDX patches :-D
> 
> I'm making good progress and the massive refactor is mostly complete.
> I believe I should have the patches ready to review next week.
> 
> I'm also thinking that it would be easier if I split the series in 2
> or possibly 3 patchset. The first one including the setup code and the
> basic lifecycle test and then the rest of the tests with possibly the
> guest_memfd tests in a separate series. What do you think?

Yes, please.  Even if we end up having to tweak a few APIs when the fancier tests
come along, I think it'll be easier and faster overall to hammer out the core
support first.

On Mon, Aug 11, 2025 at 1:12 PM Edgecombe, Rick P
<rick.p.edgecombe@intel.com> wrote:
>
> On Mon, 2025-08-11 at 10:38 -0700, Sean Christopherson wrote:
> > Please make cleaning up this mess the highest priority for TDX upstreaming.  I
> > am _thrilled_ (honestly) at the amount test coverage that has been developed for
> > TDX.  But I am equally angry that so much effort is being put into newfangled
> > TDX features, and that so little effort is being put into helping review and
> > polish this series.  I refuse to believe that I am the only person that could
> > look at the above code and come to the conclusion that it's simply unnacceptable.
>
> We were talking about this internally. Behind the scenes Reinette had actually
> spent a pretty large amount of time (the majority?) cleaning this series up
> actually, to even this level. This was some code cleanup, but also functional
> stuff like rooting out bugs where tests would give false positive passes. But
> the plan of action was to have some other TDX developers start reviewing it on
> the Intel side. I was also wondering how much time Sagi has to spend on it for
> follow on versions? We might want to think about a more direct process for
> changes->posting depending on if Sagi is able to spend more time.
>
> But Sean, if you want to save some time I think we can just accelerate this
> other reviewing. As far as new-fangled features, having this upstream is
> important even for that, because we are currently having to keep these tests
> plus follow on tests in sync across various development branches. So yea, it's
> time to get this over the line.

Thanks for the feedback Sean, I really appreciate you taking the time
to review the series.

I do have time to work on this one this week. I'm hoping to send an
updated version by the end of the week.