mbox series

[v2,00/13] x86/virt/tdx: Add SEAMCALL wrappers for KVM

Message ID 20250101074959.412696-1-pbonzini@redhat.com (mailing list archive)
Headers show
Series x86/virt/tdx: Add SEAMCALL wrappers for KVM | expand

Message

Paolo Bonzini Jan. 1, 2025, 7:49 a.m. UTC
This is a completed version of Rick's RFC series at
https://lore.kernel.org/r/20241203010317.827803-1-rick.p.edgecombe@intel.com/.
Due to EPANETTONE I didn't use the latest RFC, which is fixed here.

As in the patches that I sent ten minutes ago, I took all the "Add
SEAMCALL wrappers" patches from the various TDX parts and placed them
in a single series, so that they can be reviewed and provided in a topic
branch by Dave.

I will rebase kvm-coco-queue on top of these, but I almost definitely
will not manage to finish and push the result before getting the first
NMIs from the rest of the family.  In the meanwhile, this gives people
time to review while I'm not available.

Paolo

Isaku Yamahata (6):
  x86/virt/tdx: Add SEAMCALL wrapper tdh_mem_sept_add() to add SEPT
    pages
  x86/virt/tdx: Add SEAMCALL wrappers to add TD private pages
  x86/virt/tdx: Add SEAMCALL wrappers to manage TDX TLB tracking
  x86/virt/tdx: Add SEAMCALL wrappers to remove a TD private page
  x86/virt/tdx: Add SEAMCALL wrappers for TD measurement of initial
    contents
  x86/virt/tdx: Add tdx_guest_keyid_alloc/free() to alloc and free TDX
    guest KeyID

Kai Huang (1):
  x86/virt/tdx: Read essential global metadata for KVM

Rick Edgecombe (6):
  x86/virt/tdx: Add SEAMCALL wrappers for TDX KeyID management
  x86/virt/tdx: Add SEAMCALL wrappers for TDX TD creation
  x86/virt/tdx: Add SEAMCALL wrappers for TDX vCPU creation
  x86/virt/tdx: Add SEAMCALL wrappers for TDX page cache management
  x86/virt/tdx: Add SEAMCALL wrappers for TDX VM/vCPU field access
  x86/virt/tdx: Add SEAMCALL wrappers for TDX flush operations

Yuan Yao (1):
  [WORKAROUND] x86/virt/tdx: Retry seamcall when TDX_OPERAND_BUSY with
    operand SEPT

 arch/x86/include/asm/tdx.h                  |  50 +++
 arch/x86/virt/vmx/tdx/tdx.c                 | 432 ++++++++++++++++++++
 arch/x86/virt/vmx/tdx/tdx.h                 |  46 ++-
 arch/x86/virt/vmx/tdx/tdx_global_metadata.c |  50 +++
 arch/x86/virt/vmx/tdx/tdx_global_metadata.h |  19 +
 5 files changed, 590 insertions(+), 7 deletions(-)

Comments

Edgecombe, Rick P Jan. 2, 2025, 7:43 p.m. UTC | #1
On Wed, 2025-01-01 at 02:49 -0500, Paolo Bonzini wrote:
> This is a completed version of Rick's RFC series at
> https://lore.kernel.org/r/20241203010317.827803-1-rick.p.edgecombe@intel.com/.

Thanks!

> Due to EPANETTONE I didn't use the latest RFC, which is fixed here.
> 
> As in the patches that I sent ten minutes ago, I took all the "Add
> SEAMCALL wrappers" patches from the various TDX parts and placed them
> in a single series, so that they can be reviewed and provided in a topic
> branch by Dave.

The last plan was to have host metadata go through tip (currently v9 is queued
in tip "x86/tdx"), and everything else go through KVM tree with Dave acks. I
don't see any big problem in changing that, but we had been telling him to
expect to just give acks on the other patches. The reason to separate them that
way was because the other patches were tightly related to KVM's usage, where as
has host metadata had other users in mind too. Do you want to change that plan?
I mention this because I'm not sure if you were objecting to the current state
or just slipped the mind.

Also, did you see that Dave had acked patches 1 through 6? So if you are good
with them too, then I think we should call those done. For the MMU ones, Yan has
some updates to try to address Dave's general feedback from the first batch of
SEAMCALLs. We can comment the updates.

For the others, I had pinged Dave on "x86/virt/tdx: Read essential global
metadata for KVM" before the break, but missed that "x86/virt/tdx: Add SEAMCALL
wrappers for TDX KeyID management" had Dave's general agreement but not an
offical ack. If we collect acks on those last two, we should have everything
needed to queue "VM/vCPU creation".

> 
> I will rebase kvm-coco-queue on top of these, but I almost definitely
> will not manage to finish and push the result before getting the first
> NMIs from the rest of the family.  In the meanwhile, this gives people
> time to review while I'm not available.

You mentioned wanting to use it as an exercise to learn the code, so I'll leave
it to you.