From: Isaku Yamahata <isaku.yamahata@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>,
Xiaoyao Li <xiaoyao.li@intel.com>,
"davidskidmore@google.com" <davidskidmore@google.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pankaj.gupta@amd.com" <pankaj.gupta@amd.com>,
"srutherford@google.com" <srutherford@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Wei Wang <wei.w.wang@intel.com>,
Isaku Yamahata <isaku.yamahata@intel.com>,
isaku.yamahata@linux.intel.com
Subject: Re: [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy
Date: Tue, 9 Apr 2024 18:12:40 -0700 [thread overview]
Message-ID: <20240410011240.GA3039520@ls.amr.corp.intel.com> (raw)
In-Reply-To: <ZhQ8UCf40UeGyfE_@google.com>
On Mon, Apr 08, 2024 at 06:51:40PM +0000,
Sean Christopherson <seanjc@google.com> wrote:
> On Mon, Apr 08, 2024, Edgecombe, Rick P wrote:
> > On Mon, 2024-04-08 at 09:20 -0700, Sean Christopherson wrote:
> > > > Another option is that, KVM doesn't allow userspace to configure
> > > > CPUID(0x8000_0008).EAX[7:0]. Instead, it provides a gpaw field in struct
> > > > kvm_tdx_init_vm for userspace to configure directly.
> > > >
> > > > What do you prefer?
> > >
> > > Hmm, neither. I think the best approach is to build on Gerd's series to have KVM
> > > select 4-level vs. 5-level based on the enumerated guest.MAXPHYADDR, not on
> > > host.MAXPHYADDR.
> >
> > So then GPAW would be coded to basically best fit the supported guest.MAXPHYADDR within KVM. QEMU
> > could look at the supported guest.MAXPHYADDR and use matching logic to determine GPAW.
>
> Off topic, any chance I can bribe/convince you to wrap your email replies closer
> to 80 chars, not 100? Yeah, checkpath no longer complains when code exceeds 80
> chars, but my brain is so well trained for 80 that it actually slows me down a
> bit when reading mails that are wrapped at 100 chars.
>
> > Or are you suggesting that KVM should look at the value of CPUID(0X8000_0008).eax[23:16] passed from
> > userspace?
>
> This. Note, my pseudo-patch incorrectly looked at bits 15:8, that was just me
> trying to go off memory.
>
> > I'm not following the code examples involving struct kvm_vcpu. Since TDX
> > configures these at a VM level, there isn't a vcpu.
>
> Ah, I take it GPAW is a VM-scope knob? I forget where we ended up with the ordering
> of TDX commands vs. creating vCPUs. Does KVM allow creating vCPU structures in
> advance of the TDX INIT call? If so, the least awful solution might be to use
> vCPU0's CPUID.
The current order is, KVM vm creation (KVM_CREATE_VM),
KVM vcpu creation(KVM_CREATE_VCPU), TDX VM initialization (KVM_TDX_INIT_VM).
and TDX VCPU initialization(KVM_TDX_INIT_VCPU).
We can call KVM_SET_CPUID2 before KVM_TDX_INIT_VM. We can remove cpuid part
from struct kvm_tdx_init_vm by vcpu0 cpuid.
--
Isaku Yamahata <isaku.yamahata@intel.com>
next prev parent reply other threads:[~2024-04-10 1:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-05 16:58 [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy Sean Christopherson
2024-04-07 3:15 ` Xiaoyao Li
2024-04-08 16:20 ` Sean Christopherson
2024-04-08 17:42 ` Edgecombe, Rick P
2024-04-08 18:51 ` Sean Christopherson
2024-04-08 21:56 ` Edgecombe, Rick P
2024-04-08 22:36 ` Sean Christopherson
2024-04-08 23:46 ` Edgecombe, Rick P
2024-04-09 1:37 ` Sean Christopherson
2024-04-09 14:46 ` Edgecombe, Rick P
2024-04-09 15:23 ` Sean Christopherson
2024-04-09 15:49 ` Edgecombe, Rick P
2024-04-09 16:13 ` Xiaoyao Li
2024-04-09 16:18 ` Xiaoyao Li
2024-04-10 1:05 ` Huang, Kai
2024-04-09 16:26 ` Sean Christopherson
2024-04-11 1:13 ` Edgecombe, Rick P
2024-04-11 14:22 ` Sean Christopherson
2024-04-11 15:16 ` Xiaoyao Li
2024-04-11 15:26 ` Sean Christopherson
2024-04-11 15:41 ` Xiaoyao Li
2024-04-11 18:52 ` Edgecombe, Rick P
2024-04-12 8:40 ` Xiaoyao Li
2024-04-12 17:39 ` Isaku Yamahata
2024-04-12 20:05 ` Edgecombe, Rick P
2024-04-15 21:04 ` Isaku Yamahata
2024-04-10 1:12 ` Isaku Yamahata [this message]
2024-04-10 14:03 ` Huang, Kai
2024-04-11 1:03 ` Isaku Yamahata
2024-04-11 3:46 ` Isaku Yamahata
2024-04-11 13:39 ` Huang, Kai
2024-04-09 2:57 ` Xiaoyao Li
2024-04-09 14:01 ` Sean Christopherson
2024-04-09 14:15 ` Xiaoyao Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240410011240.GA3039520@ls.amr.corp.intel.com \
--to=isaku.yamahata@intel.com \
--cc=davidskidmore@google.com \
--cc=isaku.yamahata@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pankaj.gupta@amd.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=srutherford@google.com \
--cc=wei.w.wang@intel.com \
--cc=xiaoyao.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox