From: Yan Zhao <yan.y.zhao@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Huang, Kai" <kai.huang@intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"Yamahata, Isaku" <isaku.yamahata@intel.com>
Subject: Re: [PATCH 08/13] x86/virt/tdx: Add SEAMCALL wrappers to add TD private pages
Date: Wed, 15 Jan 2025 13:49:54 +0800 [thread overview]
Message-ID: <Z4dMgs7BKmmuaXeM@yzhao56-desk.sh.intel.com> (raw)
In-Reply-To: <be581731-07e0-4d5c-bee6-1eb653b7b72d@redhat.com>
On Wed, Jan 15, 2025 at 12:32:24AM +0100, Paolo Bonzini wrote:
> On 1/6/25 06:50, Yan Zhao wrote:
> > Yeah.
> > So, do you think we need to have tdh_mem_page_aug() to support 4K level page
> > only and ask for Dave's review again for huge page?
>
> You're right that TDH.MEM.PAGE.AUG is basically the only case in which a
> struct folio is involved; on the other hand that also means that the
> arch/x86/virt part of large page support will be tiny and I don't think it
> will be a problem to review it again (for either Dave or myself).
>
> > Do we need to add param "level" ?
> > - if yes, "struct page" looks not fit.
>
> Maybe, but I think adding folio knowledge now would be a bit too
> hypothetical.
>
> > - if not, hardcode it as 0 in the wrapper and convert "pfn" to "struct page"?
>
> I think it makes sense to add "int level" now everywhere, even if it is just
> to match the SEPT API and to have the same style for computing the SEAMCALL
> arguments. I'd rather keep the arguments simple with just "gpa | level"
> (i.e. gpa/level instead of gfn/level) as the computation: that's because gpa
> is more obviously a u64.
>
> I've pushed to kvm-coco-queue; if you have some time to double check what I
> did that's great, otherwise if I don't hear from you I'll post around noon
> European time the v3 of this series.
For tdh_mem_sept_add(), tdh_mem_page_aug(), tdh_mem_page_add()
- Use tdx_clflush_page() instead of invoking clflush_cache_range() directly to
share the common comment of tdx_clflush_page().
- prefer page_to_phy() over page_to_pfn()?
https://lore.kernel.org/kvm/0070a616-5233-4a8d-8797-eb9f182f074d@intel.com/
4d0824a1daba ("x86/virt/tdx: Add SEAMCALL wrappers to add TD private pages")
contains unexpected changes to tdh_mem_sept_add().
u64 tdh_mem_sept_add(struct tdx_td *td, u64 gpa, int level, struct page *page, u64 *ext_err1, u64 *ext_err2)
{
+ u64 hpa = page_to_pfn(page) << PAGE_SHIFT;
struct tdx_module_args args = {
.rcx = gpa | level,
.rdx = tdx_tdr_pa(td),
- .r8 = page_to_pfn(page) << PAGE_SHIFT,
+ .r8 = hpa,
};
u64 ret;
- clflush_cache_range(page_to_virt(page), PAGE_SIZE);
+ clflush_cache_range(__va(hpa), PAGE_SIZE);
ret = seamcall_ret(TDH_MEM_SEPT_ADD, &args);
*ext_err1 = args.rcx;
@@ -1522,6 +1544,26 @@ u64 tdh_vp_addcx(struct tdx_vp *vp, struct page *tdcx_page)
}
EXPORT_SYMBOL_GPL(tdh_vp_addcx);
>
> I have also asked Amazon, since they use KVM without struct page, whether it
> is a problem to have struct page pervasively in the API and they don't care.
>
> Paolo
>
next prev parent reply other threads:[~2025-01-15 5:51 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-01 7:49 [PATCH v2 00/13] x86/virt/tdx: Add SEAMCALL wrappers for KVM Paolo Bonzini
2025-01-01 7:49 ` [PATCH 01/13] x86/virt/tdx: Add SEAMCALL wrappers for TDX KeyID management Paolo Bonzini
2025-01-02 19:44 ` Edgecombe, Rick P
2025-01-01 7:49 ` [PATCH 02/13] x86/virt/tdx: Add SEAMCALL wrappers for TDX TD creation Paolo Bonzini
2025-01-03 17:51 ` Edgecombe, Rick P
2025-01-01 7:49 ` [PATCH 03/13] x86/virt/tdx: Add SEAMCALL wrappers for TDX vCPU creation Paolo Bonzini
2025-01-01 7:49 ` [PATCH 04/13] x86/virt/tdx: Add SEAMCALL wrappers for TDX page cache management Paolo Bonzini
2025-01-01 7:49 ` [PATCH 05/13] x86/virt/tdx: Add SEAMCALL wrappers for TDX VM/vCPU field access Paolo Bonzini
2025-01-01 7:49 ` [PATCH 06/13] x86/virt/tdx: Add SEAMCALL wrappers for TDX flush operations Paolo Bonzini
2025-01-01 7:49 ` [PATCH 07/13] x86/virt/tdx: Add SEAMCALL wrapper tdh_mem_sept_add() to add SEPT pages Paolo Bonzini
2025-01-02 21:59 ` Edgecombe, Rick P
2025-01-07 5:27 ` Yan Zhao
2025-01-07 19:48 ` Dave Hansen
2025-01-08 1:12 ` Yan Zhao
2025-01-08 1:20 ` Dave Hansen
2025-01-08 1:43 ` Edgecombe, Rick P
2025-01-08 2:14 ` Yan Zhao
2025-01-01 7:49 ` [PATCH 08/13] x86/virt/tdx: Add SEAMCALL wrappers to add TD private pages Paolo Bonzini
2025-01-02 23:32 ` Edgecombe, Rick P
2025-01-06 5:50 ` Yan Zhao
2025-01-06 19:21 ` Edgecombe, Rick P
2025-01-07 6:37 ` Yan Zhao
2025-01-14 23:32 ` Paolo Bonzini
2025-01-15 0:49 ` Edgecombe, Rick P
2025-01-15 2:02 ` Edgecombe, Rick P
2025-01-15 5:49 ` Yan Zhao [this message]
2025-01-01 7:49 ` [PATCH 09/13] x86/virt/tdx: Add SEAMCALL wrappers to manage TDX TLB tracking Paolo Bonzini
2025-01-03 1:28 ` Edgecombe, Rick P
2025-01-07 6:40 ` Yan Zhao
2025-01-01 7:49 ` [PATCH 10/13] x86/virt/tdx: Add SEAMCALL wrappers to remove a TD private page Paolo Bonzini
2025-01-03 1:36 ` Edgecombe, Rick P
2025-01-07 6:43 ` Yan Zhao
2025-01-07 6:52 ` Yan Zhao
2025-01-07 22:13 ` Dave Hansen
2025-01-08 0:41 ` Yan Zhao
2025-01-08 16:31 ` Dave Hansen
2025-01-09 2:19 ` Yan Zhao
2025-01-01 7:49 ` [PATCH 11/13] x86/virt/tdx: Add SEAMCALL wrappers for TD measurement of initial contents Paolo Bonzini
2025-01-03 18:02 ` Edgecombe, Rick P
2025-01-14 22:03 ` Paolo Bonzini
2025-01-14 22:10 ` Dave Hansen
2025-01-15 1:24 ` Yan Zhao
2025-01-07 7:01 ` Yan Zhao
2025-01-07 22:05 ` Dave Hansen
2025-01-01 7:49 ` [PATCH 12/13] x86/virt/tdx: Read essential global metadata for KVM Paolo Bonzini
2025-01-03 18:26 ` Edgecombe, Rick P
2025-01-01 7:49 ` [PATCH 13/13] x86/virt/tdx: Add tdx_guest_keyid_alloc/free() to alloc and free TDX guest KeyID Paolo Bonzini
2025-01-02 19:43 ` [PATCH v2 00/13] x86/virt/tdx: Add SEAMCALL wrappers for KVM Edgecombe, Rick P
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=Z4dMgs7BKmmuaXeM@yzhao56-desk.sh.intel.com \
--to=yan.y.zhao@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=isaku.yamahata@intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.