From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Rick P Edgecombe <rick.p.edgecombe@intel.com>,
Isaku Yamahata <isaku.yamahata@intel.com>,
Wei W Wang <wei.w.wang@intel.com>,
David Skidmore <davidskidmore@google.com>,
Steve Rutherford <srutherford@google.com>,
Pankaj Gupta <pankaj.gupta@amd.com>
Subject: Re: [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy
Date: Sun, 7 Apr 2024 11:15:02 +0800 [thread overview]
Message-ID: <73b40363-1063-4cb3-b744-9c90bae900b5@intel.com> (raw)
In-Reply-To: <20240405165844.1018872-1-seanjc@google.com>
On 4/6/2024 12:58 AM, Sean Christopherson wrote:
> - For guest MAXPHYADDR vs. GPAW, rely on KVM_GET_SUPPORTED_CPUID to enumerate
> the usable MAXPHYADDR[2], and simply refuse to enable TDX if the TDX Module
> isn't compatible. Specifically, if MAXPHYADDR=52, 5-level paging is enabled,
> but the TDX-Module only allows GPAW=0, i.e. only supports 4-level paging.
So userspace can get supported GPAW from usable MAXPHYADDR, i.e.,
CPUID(0X8000_0008).eaxx[23:16] of KVM_GET_SUPPORTED_CPUID:
- if usable MAXPHYADDR == 52, supported GPAW is 0 and 1.
- if usable MAXPHYADDR <= 48, supported GPAW is only 0.
There is another thing needs to be discussed. How does userspace
configure GPAW for TD guest?
Currently, KVM uses CPUID(0x8000_0008).EAX[7:0] in struct
kvm_tdx_init_vm::cpuid.entries[] of IOCTL(KVM_TDX_INIT_VM) to deduce the
GPAW:
int maxpa = 36;
entry = kvm_find_cpuid_entry2(cpuid->entries, cpuid->nent, 0x80000008, 0);
if (entry)
max_pa = entry->eax & 0xff;
...
if (!cpu_has_vmx_ept_5levels() && max_pa > 48)
return -EINVAL;
if (cpu_has_vmx_ept_5levels() && max_pa > 48) {
td_params->eptp_controls |= VMX_EPTP_PWL_5;
td_params->exec_controls |= TDX_EXEC_CONTROL_MAX_GPAW;
} else {
td_params->eptp_controls |= VMX_EPTP_PWL_4;
}
The code implies that KVM allows the provided
CPUID(0x8000_0008).EAX[7:0] to be any value (when 5level ept is
supported). when it > 48, configure GPAW of TD to 1, otherwise to 0.
However, the virtual value of CPUID(0x8000_0008).EAX[7:0] inside TD is
always the native value of hardware (for current TDX).
So if we want to keep this behavior, we need to document it somewhere
that CPUID(0x8000_0008).EAX[7:0] in struct
kvm_tdx_init_vm::cpuid.entries[] of IOCTL(KVM_TDX_INIT_VM) is only for
configuring GPAW, not for userspace to configure virtual CPUID value for
TD VMs.
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?
> [1]https://drive.google.com/corp/drive/folders/1hm_ITeuB6DjT7dNd-6Ezybio4tRRQOlC
> [2]https://lore.kernel.org/all/20240313125844.912415-1-kraxel@redhat.com
next prev parent reply other threads:[~2024-04-07 3:15 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-05 16:58 Sean Christopherson
2024-04-07 3:15 ` Xiaoyao Li [this message]
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
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=73b40363-1063-4cb3-b744-9c90bae900b5@intel.com \
--to=xiaoyao.li@intel.com \
--cc=davidskidmore@google.com \
--cc=isaku.yamahata@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 \
/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
all inboxes | Powered by JetHome®