[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5c8228769f27244f2f1435a74879a0ab64c3df97.camel@intel.com>
Date: Thu, 2 Jan 2025 19:43:35 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
<pbonzini@...hat.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
CC: "Zhao, Yan Y" <yan.y.zhao@...el.com>, "Huang, Kai" <kai.huang@...el.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v2 00/13] x86/virt/tdx: Add SEAMCALL wrappers for KVM
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.
Powered by blists - more mailing lists