* Re: [RFC PATCH 09/15] x86/virt/tdx: Add interface to generate a Quote
From: Peter Fang @ 2026-06-14 11:29 UTC (permalink / raw)
To: Edgecombe, Rick P
Cc: kas@kernel.org, djbw@kernel.org, yilun.xu@linux.intel.com,
x86@kernel.org, Xu, Yilun, Duan, Zhenzhong,
baolu.lu@linux.intel.com, Li, Xiaoyao,
linux-kernel@vger.kernel.org, Mehta, Sohil, kvm@vger.kernel.org,
linux-coco@lists.linux.dev
In-Reply-To: <a10ad58ed8092e4e7d81be1995438efd21647fde.camel@intel.com>
On Thu, May 28, 2026 at 03:30:45PM -0700, Edgecombe, Rick P wrote:
> > +
> > + /* TDH.QUOTE.GET expects the input data to fit in a page */
> > + if (in_data_len > PAGE_SIZE)
> > + return NULL;
>
> Do we really need this check? We can't trust the caller to pass the right size?
There is a similar check for this in_data_len on the KVM side in patch
12, but it is for a different reason. The check in KVM is to make sure
it maps valid guest memory pages into the kernel, while here we make
sure it complies with the SEAMCALL API. That said, the KVM check does
make the check here kinda redundant... I can remove this for simplicity.
>
> > +
> > + mutex_lock(&tdx_quote_lock);
> > +
> > + /*
> > + * Use the first page of the quote buffer for input data. The buffer
> > + * must be at least one page in size. @in_data may not be page-aligned,
> > + * but TDH.QUOTE.GET expects page-aligned addresses.
> > + */
> > + memcpy(quote_data.buf, in_data, (size_t)in_data_len);
> > +
> > + r = tdx_quote_get(td, quote_data.hpa_list[0], (u64)in_data_len,
> > + quote_data.hpa_list_pa, quote_data.buf_len, &out_len);
> > + if (r || !out_len || out_len > quote_data.buf_len)
>
>
> How do these various error conditions happen?
"r" is a SEAMCALL error just like any other SEAMCALL. If r == 0
(SUCCESS), there is no documented scenario for when "!out_len" or
"out_len > quote_data.buf_len" would occur. I would assume these would
be TDX module bugs.
The reason I check the last 2 conditions is mainly to protect the
kernel:
- "!out_len" will cause kvmemdup() to return ZERO_SIZE_PTR
- "out_len > quote_data.buf_len" will cause out-of-bounds memory
access in kvmemdup()
>
> > + goto out;
> > +
> > + /*
> > + * The quote buffer is a shared resource, so use it only for the
> > + * SEAMCALL and copy the data out as soon as possible.
> > + */
> > + quote_dup = kvmemdup(quote_data.buf, out_len, GFP_KERNEL);
>
> So at init time we allocate a vmalloc for the quote and pre-populate the
> hpa_list. Then we use it every time and copy the contents to a new vmalloc.
> Would it really be that hard to keep the hpa list allocation around, do a
> vmalloc here and update the pfn list. Then do get quote on that and pass back
> the vmalloc we just allocated? Just feels like global reuse way has extra pieces
> in it. Compared to the whole quoting operation, this vmalloc_to_pfn() loop is
> probably not very expensive.
Hm interesting idea. But a Quote buffer could be close to 4MB in the worst
case. Let's say max_quote_size is 3MB, that's 768 vmalloc_to_pfn() calls
each time... That sounds a bit excessive right?
The extra bits mainly come from using kvmemdup() I think. Having to use
kvfree() on it does feel a bit annoying but that was the tradeoff I
made...
>
^ permalink raw reply
* Re: [RFC PATCH 07/15] x86/virt/tdx: Prepare Quote buffer during extension bringup
From: Peter Fang @ 2026-06-14 10:28 UTC (permalink / raw)
To: Edgecombe, Rick P
Cc: kas@kernel.org, djbw@kernel.org, yilun.xu@linux.intel.com,
x86@kernel.org, Xu, Yilun, Duan, Zhenzhong,
baolu.lu@linux.intel.com, Li, Xiaoyao,
linux-kernel@vger.kernel.org, Mehta, Sohil, kvm@vger.kernel.org,
linux-coco@lists.linux.dev
In-Reply-To: <1a4d1126d6fe86e94fa8e1de6764656853e61106.camel@intel.com>
On Thu, May 28, 2026 at 03:30:36PM -0700, Edgecombe, Rick P wrote:
> On Fri, 2026-05-22 at 11:41 +0800, Xu Yilun wrote:
> > From: Peter Fang <peter.fang@intel.com>
> >
> > The host uses a Quote buffer to communicate with the TDX module when
> > generating Quotes.
> >
>
> Can this be put in common terms. This is going to mean nothing to someone
> reading this that doesn't already know the feature.
I'll add more background in common terms here.
>
> > Because the Quote buffer is shared with TDX guests,
>
> Why capitalize "Quote"?
This is again the balance between using common terms vs TDX language. In
general, TDX docs capitalize terms a lot. TDX attestation docs always
refer to the attestation blob as "Quotes".
I mainly went with "Quotes" in the logs because that term has already
been used everywhere in the tdx-guest code/logs (see tdx-guest.c). So I
wanted to preserve some consistency at least in the logs. In the added
host code and prints, I'm starting to just use "quotes" because that
seems to be the more common convention in the TDX host code. I'm happy
to make adjustments if this doesn't make sense.
>
> > prepare the required metadata during Quoting extension bringup.
>
> What does prepare the required metadata mean?
That's a poor choice of word on my part. I'll rephrase it in the next
revision. I mainly just wanted to convey "prepare struct quote_data".
>
> How does it being shared with TDX guest suggest this? Just that TDX guests will
> need them? Is the reason just that only one is needed, so do it during global
> init?
Yes, that's exactly it. I'll make it clearer.
>
> > +static struct quote_data {
> > + void *buf;
> > + u64 buf_len;
> > + u64 *hpa_list;
> > + phys_addr_t hpa_list_pa;
> > +} quote_data;
>
> Hmm, I think this should separate the type and variable declaration. It's not a
> common pattern. I don't think there is an official rule.
Sure, I'll fix this.
>
> > + qlist = vmalloc_array(qlist_npages, PAGE_SIZE);
> > + if (!qlist) {
> > + err = -ENOMEM;
> > + goto out_err;
>
> Just return ENOMEM here. vfree() doesn't do any work if passed NULL, but it's
> weird flow.
Will do.
>
> > + }
> > +
> > + /*
> > + * Make sure unfilled entries are always -1, which means NULL in TDX.
>
> Huh?
I'll add more explanation here (see below).
>
> > + * Only the last page needs to be filled. All the other pages will be
> > + * fully populated.
> > + */
> > + memset((u8 *)qlist + (qlist_npages - 1) * PAGE_SIZE, 0xff, PAGE_SIZE);
>
> What are the entries? And what is a -1 in u8? Or is it supposed to be u64?
> Please make this a lot clearer.
Yeah I was trying to create all-1 u64 entries. This is pretty
under-commented. I'll redo the comments.
>
> > + /* Populate HPA_LINKED_LIST as per TDX ABI spec */
> > + for (i = 0, j = 0; j < nr_pages; i++) {
> > + if ((i % HPAS_PER_PAGE) == HPAS_PER_PAGE - 1) {
> > + /*
> > + * The last entry always points to the next page. The
> > + * address of the following entry must be on next page's
> > + * boundary.
> > + */
>
> Can you maybe just explain this format that you are building in like one
> sentence at the beginning of the function? "The quote buffer is passed to the
> tdx module in a format that like... (some common terms that have no TDX
> jargon)."
Will do. This part is pretty under-commented as well.
>
> > + qdata->buf = qbuf;
> > + qdata->buf_len = (u64)nr_pages * PAGE_SIZE;
> > + qdata->hpa_list = qlist;
> > +
> > + pfn = vmalloc_to_pfn(qlist);
>
> Do we need a vmalloc_to_pa() helper? Maybe put it in terms of tdx format. Like
> vmalloc_pfn_to_tdxpa() and keep it here? The tdx update stuff does this a bunch
> too.
That's a really good idea. I'll do that.
>
> > + qdata->hpa_list_pa = PFN_PHYS(pfn);
> > +
> > + return 0;
> > +
> > +out_err:
> > + vfree(qlist);
> > +
> > + return err;
>
> It only returns -ENOMEM, so do we need the err var?
Good point. I think I had some other errors that I later removed. I'll
just return -ENOMEM directly here.
>
> > +}
> > +
> > static void tdx_quote_init(void)
> > {
> > struct tdx_module_args args = {};
> > + unsigned int nr_quote_pages;
> > u64 r;
> >
> > do {
> > @@ -1218,7 +1295,13 @@ static void tdx_quote_init(void)
> > return;
> >
> > /* Quoting metadata is valid only after initialization */
> > - get_tdx_sys_info_quote(&tdx_sysinfo.quote);
> > + if (get_tdx_sys_info_quote(&tdx_sysinfo.quote))
> > + return;
>
> How come this patch gets error handling? Why is it needed now when it wasn't
> before?
Previously, get_tdx_sys_info_quote() just happened to be the last
statement in tdx_quote_init() so getting an error didn't require an
early return. tdx_quote_init() wasn't doing much at the time. But now
the code can't see a valid max_quote_size if get_tdx_sys_info_quote()
fails.
>
> > +
> > + nr_quote_pages = PAGE_ALIGN(tdx_sysinfo.quote.max_quote_size) /
> > + PAGE_SIZE;
> > + if (tdx_quote_create_buf(nr_quote_pages, "e_data))
> > + pr_err("Failed to create quote buffer\n");
>
> Err... what happens in ENOMEM scenario? NULL pointer later?
Yes. struct quote_data remains uninitialized so it will have NULL
pointers. All the added APIs will take this into account so there won't
be NULL pointer accesses.
>
> > }
> >
> > /* Initialize the TDX Module Extensions then Extension-SEAMCALLs can be used */
>
^ permalink raw reply
* Re: [RFC PATCH 06/15] x86/virt/tdx: Initialize Quoting extension during bringup
From: Peter Fang @ 2026-06-14 7:50 UTC (permalink / raw)
To: Dan Williams (nvidia)
Cc: Xu Yilun, kas, rick.p.edgecombe, x86, linux-coco, linux-kernel,
kvm, sohil.mehta, yilun.xu, baolu.lu, zhenzhong.duan, xiaoyao.li
In-Reply-To: <6a2c9d8b8bfe9_9b85510018@djbw-dev.notmuch>
On Fri, Jun 12, 2026 at 05:00:11PM -0700, Dan Williams (nvidia) wrote:
> Xu Yilun wrote:
> > From: Peter Fang <peter.fang@intel.com>
> >
> > Initialize the Quoting extension and fetch its metadata during TDX
> > bringup.
> >
> > Because Quoting is an optional TDX feature, do not let its
> > initialization failures cause TDX bringup to fail.
>
> Is this micro-optimization worth it? What are the classes of quote-init
> failures vs just make the policy be anything in the module must init.
Since there is a fallback option to do the Quoting in userspace, I think
it is probably not worth shooting down TDX entirely over quote-init
failures.
The quote-init failures can come from:
1. Quoting init SEAMCALL failures, which look pretty opaque to the
kernel and there's not much it can do about it.
2. Quoting buffer allocation failures, which *are* understood by the
kernel, and it could maybe try something else. Right now, we just
treat it the same as 1.
This is helpful because I think the question of "what if the Quoting
extension fails" has come up enough times that it warrants some
explanation in the patch log. Thanks.
>
> > This patch does not include the opt-in portion of the initialization.
> > It mainly lays the groundwork for TDX Quoting support. Opt-in will be
> > added in a follow-up patch once the feature can be properly used by the
> > system.
>
> It is unconditionally calling quote init even if the feature is not
> present. Is that not a problem?
Good question... I should reorder the patches so this looks more
straightforward. I enable everything in patch 15 (including the check
for the Quoting feature) and I think that just creates confusion for
folks looking at this patch.
>
^ permalink raw reply
* Re: [RFC PATCH 06/15] x86/virt/tdx: Initialize Quoting extension during bringup
From: Peter Fang @ 2026-06-14 7:20 UTC (permalink / raw)
To: Adrian Hunter
Cc: Xu Yilun, kas, djbw, rick.p.edgecombe, x86, linux-coco,
linux-kernel, kvm, sohil.mehta, yilun.xu, baolu.lu,
zhenzhong.duan, xiaoyao.li
In-Reply-To: <55b1972a-bfc9-4229-a7c6-7d46b03d9e6c@intel.com>
On Thu, Jun 11, 2026 at 07:22:18PM +0300, Adrian Hunter wrote:
> On 22/05/2026 06:41, Xu Yilun wrote:
> > From: Peter Fang <peter.fang@intel.com>
> >
> > Initialize the Quoting extension and fetch its metadata during TDX
> > bringup.
> >
> > Because Quoting is an optional TDX feature, do not let its
> > initialization failures cause TDX bringup to fail.
>
> Is there a reason Linux needs to support TDX with failed Quote
> extension initialization?
The Quoting extension is not the only way to get TD Quotes. If this
extension fails, the host can still fall back to the legacy SGX-based
Quoting in userspace. I think the decision to actually fall back can be
left to userspace at that point.
>
> > +static void tdx_quote_init(void)
> > +{
> > + struct tdx_module_args args = {};
> > + u64 r;
> > +
> > + do {
> > + r = seamcall(TDH_QUOTE_INIT, &args);
> > + } while (r == TDX_INTERRUPTED_RESUMABLE);
> > +
> > + if (r)
>
> Elsewhere it tends to be:
>
> if (r != TDX_SUCCESS)
Good catch. I'll fix this. Thanks!
>
^ permalink raw reply
* Re: [RFC PATCH 06/15] x86/virt/tdx: Initialize Quoting extension during bringup
From: Peter Fang @ 2026-06-14 7:10 UTC (permalink / raw)
To: Edgecombe, Rick P
Cc: kas@kernel.org, djbw@kernel.org, yilun.xu@linux.intel.com,
x86@kernel.org, Xu, Yilun, Duan, Zhenzhong,
baolu.lu@linux.intel.com, Li, Xiaoyao,
linux-kernel@vger.kernel.org, Mehta, Sohil, kvm@vger.kernel.org,
linux-coco@lists.linux.dev
In-Reply-To: <f9ebc92839c94430055fe2a48114054a39b0e56e.camel@intel.com>
On Thu, May 28, 2026 at 02:35:49PM -0700, Edgecombe, Rick P wrote:
> On Fri, 2026-05-22 at 11:41 +0800, Xu Yilun wrote:
> > From: Peter Fang <peter.fang@intel.com>
> >
> > Initialize the Quoting extension and fetch its metadata during TDX
> > bringup.
> >
> > Because Quoting is an optional TDX feature, do not let its
> > initialization failures cause TDX bringup to fail.
> >
> > This patch
> >
>
> Don't say "this patch" in tip logs. The patch is a temporary format, and some
> x86 maintainers hate the term in logs.
Thanks, will fix in the next revision.
>
> > does not include the opt-in portion of the initialization.
> > It mainly lays the groundwork for TDX Quoting support. Opt-in will be
> > added in a follow-up patch once the feature can be properly used by the
> > system.
>
> This could be imperative mood.
Will fix this as well.
>
> >
> > Signed-off-by: Peter Fang <peter.fang@intel.com>
> > Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
>
^ permalink raw reply
* Re: [RFC PATCH 05/15] x86/virt/tdx: Move tdx_tdr_pa() up in the file
From: Peter Fang @ 2026-06-14 7:04 UTC (permalink / raw)
To: Adrian Hunter
Cc: Xu Yilun, kas, djbw, rick.p.edgecombe, x86, linux-coco,
linux-kernel, kvm, sohil.mehta, yilun.xu, baolu.lu,
zhenzhong.duan, xiaoyao.li
In-Reply-To: <0f4ee112-59c6-49b0-8d0b-886f32ec410a@intel.com>
On Thu, Jun 11, 2026 at 07:21:17PM +0300, Adrian Hunter wrote:
> On 22/05/2026 06:41, Xu Yilun wrote:
> > From: Peter Fang <peter.fang@intel.com>
> >
> > Move the tdx_tdr_pa() in preparation for upcoming changes to use them
>
> them -> it
Ack. Thanks for catching this.
>
^ permalink raw reply
* Re: [PATCH 04/15] x86/virt/tdx: Enable the Extensions right after basic TDX Module init
From: Peter Fang @ 2026-06-14 7:00 UTC (permalink / raw)
To: Xu Yilun
Cc: Kishen Maloor, kas, djbw, rick.p.edgecombe, x86, linux-coco,
linux-kernel, kvm, sohil.mehta, yilun.xu, baolu.lu,
zhenzhong.duan, xiaoyao.li
In-Reply-To: <aiaVk9Lx7iakgd4g@yilunxu-OptiPlex-7050>
On Mon, Jun 08, 2026 at 06:12:35PM +0800, Xu Yilun wrote:
>
> >
> > The handling of tdx_quote_init() in Patch 6 suggests a more
> > best-effort approach.
>
> TDX Quoting is however a clear self-contained add-on feature from OS POV.
> Though I'm not sure if a TDX platform is still a safe TCB with DICE
> available but failed, and good for "best-effort" policy? Maybe Peter
> could answer.
The DICE extension is just one of the ways to generate a Quote for the
guest. If DICE is not available, TDX can fall back to the existing
userspace SGX Quoting flow. So I think a best-effort approach makes
sense here.
> >
^ permalink raw reply
* Re: [RFC PATCH 14/15] x86/virt/tdx: Embed version info in SEAMCALL leaf function definitions
From: Xu Yilun @ 2026-06-13 15:55 UTC (permalink / raw)
To: Adrian Hunter
Cc: kas, djbw, rick.p.edgecombe, x86, peter.fang, linux-coco,
linux-kernel, kvm, sohil.mehta, yilun.xu, baolu.lu,
zhenzhong.duan, xiaoyao.li
In-Reply-To: <dd9027c7-ea84-4cee-9484-4e464a766b0d@intel.com>
On Fri, Jun 12, 2026 at 08:47:26AM +0300, Adrian Hunter wrote:
> On 22/05/2026 06:41, Xu Yilun wrote:
> > Embed version information in SEAMCALL leaf function definitions rather
> > than let the caller open code them. For now, only TDH.VP.INIT is
> > involved.
>
> > @@ -31,7 +44,7 @@
> > #define TDH_VP_CREATE 10
> > #define TDH_MNG_KEY_FREEID 20
> > #define TDH_MNG_INIT 21
> > -#define TDH_VP_INIT 22
> > +#define TDH_VP_INIT SEAMCALL_LEAF_VER(22, 1)
>
> FWIW I find the macro a bit ugly, and hiding the version number in
> the leaf number macro a little counter-intuitive compared with setting
> it at the call site. It anyway needs some explanation at the call site.
We actually discussed about this and realized we don't need to keep
version. This is because:
1. Newer version SEAMCALLs are always compatible with older ones.
2. System security requires us to stop using an older TDX module when
there is a newer one. So don't try to support an older TDX module
which doesn't understand newer version SEAMCALLs.
https://lore.kernel.org/all/ca331aa3-6304-4e07-9ed9-94dc69726382@intel.com/
>
> > @@ -2217,8 +2217,8 @@ u64 tdh_vp_init(struct tdx_vp *vp, u64 initial_rcx, u32 x2apicid)
> > .r8 = x2apicid,
> > };
> >
> > - /* apicid requires version == 1. */
> > - return seamcall(TDH_VP_INIT | (1ULL << TDX_VERSION_SHIFT), &args);
> > + /* apicid requires version == 1. See TDH_VP_INIT definition.*/
> > + return seamcall(TDH_VP_INIT, &args);
>
> Now the reader has to go look at TDH_VP_INIT.
mm.. I think I should just delete the comment.
^ permalink raw reply
* Re: [RFC PATCH 12/15] KVM: TDX: Add in-kernel Quote generation
From: Dan Williams (nvidia) @ 2026-06-13 0:20 UTC (permalink / raw)
To: Xu Yilun, kas, djbw, rick.p.edgecombe, x86, peter.fang
Cc: linux-coco, linux-kernel, kvm, sohil.mehta, yilun.xu, yilun.xu,
baolu.lu, zhenzhong.duan, xiaoyao.li
In-Reply-To: <20260522034128.3144354-13-yilun.xu@linux.intel.com>
Xu Yilun wrote:
> From: Peter Fang <peter.fang@intel.com>
>
> Provide an in-kernel path for TDX Quote generation when handling
> TDG.VP.VMCALL<GetQuote>, without requiring an exit to userspace.
>
> Use the core TDX API when the TDX Quoting extension is available. For
> simplicity, each KVM guest checks for availability only once during
> initialization. KVM does not handle Quoting service disruptions.
>
> Signed-off-by: Peter Fang <peter.fang@intel.com>
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> ---
[..]
> +static u64 __get_quote_kernel(struct kvm_vcpu *vcpu, struct tdx_quote_req *req,
> + size_t req_len, gpa_t req_gpa, size_t total_len)
> +{
> + struct tdx_td *td = &to_kvm_tdx(vcpu->kvm)->td;
> +
> + /* Only support version 1 as defined in the GHCI spec */
> + if (req->version != 1)
> + return TDX_QUOTE_STATUS_ERROR;
> +
> + if ((size_t)req->in_len + TDX_QUOTE_REQ_HDR_SIZE > req_len)
> + return TDX_QUOTE_STATUS_ERROR;
> +
> + /* The caller frees the quote data */
No, it is freed by cleanup as far as I can see
> + void *quote_data __free(kvfree) =
...this shadows the global "quote_data". A global really should be
properly namespaced.
^ permalink raw reply
* Re: [PATCH 04/15] x86/virt/tdx: Enable the Extensions right after basic TDX Module init
From: Dan Williams (nvidia) @ 2026-06-13 0:08 UTC (permalink / raw)
To: Xu Yilun, kas, djbw, rick.p.edgecombe, x86, peter.fang
Cc: linux-coco, linux-kernel, kvm, sohil.mehta, yilun.xu, yilun.xu,
baolu.lu, zhenzhong.duan, xiaoyao.li
In-Reply-To: <20260522034128.3144354-5-yilun.xu@linux.intel.com>
Xu Yilun wrote:
> The detailed initialization flow for TDX Module Extensions has been
> fully implemented. Enable the flow after basic TDX Module
> initialization.
>
> Theoretically, the Extensions doesn't need to be enabled right after
> basic TDX initialization. It could be enabled right before the first
> Extension SEAMCALL is issued. That would save or postpone memory usage.
> But it isn't worth the complexity, the needs for the Extensions are vast
> but the savings are little for a typical TDX capable system (about
> 0.001% of memory). So the Linux decision is to just enable it along with
> the basic TDX.
No real point in rehashing the rationale for the "any available, all the
time" policy yet again especially when this directly conflicts with the
"relatively large amount" comment in the original cover letter.
Otherwise I agree with the proposed reordering of this initial series.
In general though, no big showstoppers for me in this first 4.
^ permalink raw reply
* Re: [RFC PATCH 10/15] x86/tdx: Move and rename Quote request structure
From: Dan Williams (nvidia) @ 2026-06-13 0:04 UTC (permalink / raw)
To: Xu Yilun, kas, djbw, rick.p.edgecombe, x86, peter.fang
Cc: linux-coco, linux-kernel, kvm, sohil.mehta, yilun.xu, yilun.xu,
baolu.lu, zhenzhong.duan, xiaoyao.li
In-Reply-To: <20260522034128.3144354-11-yilun.xu@linux.intel.com>
Xu Yilun wrote:
> From: Peter Fang <peter.fang@intel.com>
>
> struct tdx_quote_buf is currently used only by the guest, but the Quote
> buffer format will also be needed by the host for in-kernel Quote
> generation. Move the definition to tdx.h so it can be shared by both.
>
> Rename the struct to tdx_quote_req to better reflect its purpose.
>
> Signed-off-by: Peter Fang <peter.fang@intel.com>
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> ---
> arch/x86/include/asm/tdx.h | 21 +++++++++++++++++++++
> drivers/virt/coco/tdx-guest/tdx-guest.c | 25 +++----------------------
> 2 files changed, 24 insertions(+), 22 deletions(-)
>
> diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
> index bc512a00a0d0..945e6817abb2 100644
> --- a/arch/x86/include/asm/tdx.h
> +++ b/arch/x86/include/asm/tdx.h
> @@ -96,6 +96,27 @@ static inline long tdx_kvm_hypercall(unsigned int nr, unsigned long p1,
> }
> #endif /* CONFIG_INTEL_TDX_GUEST && CONFIG_KVM_GUEST */
>
> +#if defined(CONFIG_INTEL_TDX_GUEST) || defined(CONFIG_KVM_INTEL_TDX)
> +/* struct tdx_quote_req: Format of Quote request message.
> + * @version: Quote format version, filled by TD.
> + * @status: Status code of Quote request, filled by VMM.
> + * @in_len: Length of TDREPORT, filled by TD.
> + * @out_len: Length of Quote data, filled by VMM.
> + * @data: Quote data on output or TDREPORT on input.
> + *
> + * More details of Quote request message can be found in TDX
> + * Guest-Host Communication Interface (GHCI) for Intel TDX 1.0,
> + * section titled "TDG.VP.VMCALL<GetQuote>"
> + */
> +struct tdx_quote_req {
> + u64 version;
> + u64 status;
> + u32 in_len;
> + u32 out_len;
> + u8 data[];
> +};
> +#endif /* CONFIG_INTEL_TDX_GUEST || CONFIG_KVM_INTEL_TDX */
Drop the ifdef guards.
There is no cost to allowing a data structure to be defined
unconditionally. Usually the ifdef guards are to prevent compilation
errors when symbols do not resolve.
Otherwise looks ok.
Reviewed-by: Dan Williams <djbw@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH 06/15] x86/virt/tdx: Initialize Quoting extension during bringup
From: Dan Williams (nvidia) @ 2026-06-13 0:00 UTC (permalink / raw)
To: Xu Yilun, kas, djbw, rick.p.edgecombe, x86, peter.fang
Cc: linux-coco, linux-kernel, kvm, sohil.mehta, yilun.xu, yilun.xu,
baolu.lu, zhenzhong.duan, xiaoyao.li
In-Reply-To: <20260522034128.3144354-7-yilun.xu@linux.intel.com>
Xu Yilun wrote:
> From: Peter Fang <peter.fang@intel.com>
>
> Initialize the Quoting extension and fetch its metadata during TDX
> bringup.
>
> Because Quoting is an optional TDX feature, do not let its
> initialization failures cause TDX bringup to fail.
Is this micro-optimization worth it? What are the classes of quote-init
failures vs just make the policy be anything in the module must init.
> This patch does not include the opt-in portion of the initialization.
> It mainly lays the groundwork for TDX Quoting support. Opt-in will be
> added in a follow-up patch once the feature can be properly used by the
> system.
It is unconditionally calling quote init even if the feature is not
present. Is that not a problem?
^ permalink raw reply
* Re: [PATCH 02/15] x86/virt/tdx: Add extra memory to TDX Module for Extensions
From: Dan Williams (nvidia) @ 2026-06-12 23:49 UTC (permalink / raw)
To: Xu Yilun, kas, djbw, rick.p.edgecombe, x86, peter.fang
Cc: linux-coco, linux-kernel, kvm, sohil.mehta, yilun.xu, yilun.xu,
baolu.lu, zhenzhong.duan, xiaoyao.li
In-Reply-To: <20260522034128.3144354-3-yilun.xu@linux.intel.com>
Xu Yilun wrote:
> TDX Module introduces a new concept called "TDX Module Extensions" to
> support long running / hard-irq preemptible flows inside. This makes TDX
> Module capable of handling complex tasks through "Extension SEAMCALLs".
> Adding more memory to TDX Module is the first step to enable Extensions.
Like I said on the cover, I think "long running hard-irq preemptible"
invites more questions that it answers. The service calls are not "long
running" on their own. I think it is sufficient to say they are
resumable unlike typical calls that run to completion while monopolizing
the CPU.
> Currently, TDX Module memory use is relatively static. But, the
> Extensions need to use memory more dynamically. While 'static' here
> means the kernel provides necessary amount of memory to TDX Module for
> its basic functionalities, 'dynamic' means extra memory is needed only
> if new add-on features are to be enabled. So add a new memory feeding
> process backed by a new SEAMCALL TDH.EXT.MEM.ADD.
Rick commented on this as well, but a simpler way to say it is
extensions receive a one time memory pool allocation at init time. The
extension uses that pool as its baseline for its own internal state and
data for the service APIs it offers.
> The process is mostly the same as adding PAMT. The kernel queries TDX
> Module how much memory needed, allocates it, hands it over, and never
> gets it back.
>
> TDH.EXT.MEM.ADD uses a new parameter type HPA_LIST_INFO to provide
> control (private) pages to TDX Module. This type represents a list of
> pages for TDX Module to access. It needs a 'root page' which contains
> the list of HPAs of the pages. It collapses the HPA of the root page
> and the number of valid HPAs into a 64 bit raw value for SEAMCALL
> parameters. The root page is always a medium, TDX Module never keeps
> the root page.
I mention below, but I do not think the reader cares that the TDX Module
calls an array of physical addresses a "root" page.
>
> Introduce a tdx_clflush_hpa_list() helper to flush shared cache before
> SEAMCALL, to avoid shared cache writeback damaging these private pages.
>
> For now, TDX Module Extensions consumes relatively large amount of
> memory (~50MB). Use contiguous page allocation to avoid permanently
> fragment too much memory. Print the allocation amount on TDX Module
> Extensions initialization for visibility.
To be clear I believe there is a low chance of fragmentation given this
allocation happening early. However, at 10s of MB the benefit of
isolating blocks of PFNs that will never be returned, it makes to not
use the buddy allocator for that.
> Co-developed-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> ---
> arch/x86/virt/vmx/tdx/tdx.h | 1 +
> arch/x86/virt/vmx/tdx/tdx.c | 118 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 119 insertions(+)
>
> diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h
> index a5eec8e3cc71..2335f88bbb10 100644
> --- a/arch/x86/virt/vmx/tdx/tdx.h
> +++ b/arch/x86/virt/vmx/tdx/tdx.h
> @@ -46,6 +46,7 @@
> #define TDH_PHYMEM_PAGE_WBINVD 41
> #define TDH_VP_WR 43
> #define TDH_SYS_CONFIG 45
> +#define TDH_EXT_MEM_ADD 61
> #define TDH_SYS_DISABLE 69
>
> /*
> diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> index c0c6281b08a5..622399d8da68 100644
> --- a/arch/x86/virt/vmx/tdx/tdx.c
> +++ b/arch/x86/virt/vmx/tdx/tdx.c
> @@ -31,6 +31,7 @@
> #include <linux/syscore_ops.h>
> #include <linux/idr.h>
> #include <linux/kvm_types.h>
> +#include <linux/bitfield.h>
> #include <asm/page.h>
> #include <asm/special_insns.h>
> #include <asm/msr-index.h>
> @@ -1179,6 +1180,123 @@ static __init int init_tdmrs(struct tdmr_info_list *tdmr_list)
> return 0;
> }
>
> +static void tdx_clflush_hpa_list(struct page *root, unsigned int nr_pages)
> +{
> + u64 *entries = page_to_virt(root);
> + int i;
> +
> + for (i = 0; i < nr_pages; i++)
> + clflush_cache_range(__va(entries[i]), PAGE_SIZE);
> +}
> +
> +#define HPA_LIST_INFO_FIRST_ENTRY GENMASK_U64(11, 3)
> +#define HPA_LIST_INFO_PFN GENMASK_U64(51, 12)
> +#define HPA_LIST_INFO_LAST_ENTRY GENMASK_U64(63, 55)
> +
> +static u64 to_hpa_list_info(struct page *root, unsigned int nr_pages)
> +{
> + return FIELD_PREP(HPA_LIST_INFO_FIRST_ENTRY, 0) |
> + FIELD_PREP(HPA_LIST_INFO_PFN, page_to_pfn(root)) |
> + FIELD_PREP(HPA_LIST_INFO_LAST_ENTRY, nr_pages - 1);
> +}
> +
> +static int tdx_ext_mem_add(struct page *root, unsigned int nr_pages)
> +{
> + struct tdx_module_args args = {
> + .rcx = to_hpa_list_info(root, nr_pages),
> + };
> + u64 r;
> +
> + tdx_clflush_hpa_list(root, nr_pages);
> +
> + do {
> + /*
> + * TDH_EXT_MEM_ADD is designed to use output parameter RCX to
> + * override/update input parameter RCX, so the caller doesn't
> + * have to do manual parameter update on retry call.
> + */
> + r = seamcall_ret(TDH_EXT_MEM_ADD, &args);
> + } while (r == TDX_INTERRUPTED_RESUMABLE);
> +
> + if (r != TDX_SUCCESS)
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> +static int tdx_ext_mem_setup(void)
> +{
> + unsigned int nr_pages;
> + struct page *page;
> + u64 *root;
> + unsigned int i;
> + int ret;
> +
> + nr_pages = tdx_sysinfo.ext.memory_pool_required_pages;
> + /*
> + * memory_pool_required_pages == 0 means no need to add pages,
> + * skip the memory setup.
> + */
> + if (!nr_pages)
> + return 0;
> +
> + root = kzalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!root)
> + return -ENOMEM;
I think this "root" term is a holdover from the complicated TDX Connect
case where it might sometimes be this odd "singleton" object? You could
just make it this for actual type safety.
struct tdx_hpa_list {
u64 phys[PAGE_SIZE/sizeof(u64)];
}
> +
> + page = alloc_contig_pages(nr_pages, GFP_KERNEL, numa_mem_id(),
> + &node_online_map);
> + if (!page) {
> + ret = -ENOMEM;
> + goto out_free_root;
> + }
> +
> + for (i = 0; i < nr_pages;) {
> + unsigned int nents = min(nr_pages - i,
> + PAGE_SIZE / sizeof(*root));
This looks wrong, sizeof(struct page)?, or size of physical address?
Becomes less error prone if you do:
min(nr_pages - i, ARRAY_SIZE(hpa_list->phys))
> + int j;
> +
> + for (j = 0; j < nents; j++)
You can declare j in the for loop.
> + root[j] = page_to_phys(page + i + j);
> +
> + ret = tdx_ext_mem_add(virt_to_page(root), nents);
> + /*
> + * No SEAMCALLs to reclaim the added pages. For simple error
> + * handling, leak all pages.
> + */
> + WARN_ON_ONCE(ret);
Perhaps to be friendlier to folks without the source code in front of
them drop the comment and do:
WARN(ret, "Fatal: TDX Module failed (%d) to accept memory, stranded %ld pages\n", ret, nr_pages)
...the once flavor not needed, right? It's toast at this point.
^ permalink raw reply
* Re: [PATCH v14 10/44] arm64: RMI: Add support for SRO
From: Dan Williams (nvidia) @ 2026-06-12 23:07 UTC (permalink / raw)
To: Steven Price, Gavin Shan, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <50d70588-2ebc-4c9b-98ec-68f3d04a9d21@arm.com>
Steven Price wrote:
[..]
> > alloc_pages_exact() will fail if the requested size exceeds the maximal
> > allowed
> > size (1 << MAX_PAGE_ORDER). The maximal size is usually smaller than
> > PUD_SIZE
> > but PUD_SIZE is allowed by the RMM.
>
> This is an area where to be honest I'm really not sure what to do.
> Technically the RMM is allowed to ask for a contiguous range of 512GB
> pages (on a 4K system - larger with larger page sizes) - but clearly no
> real OS is going to be able to provide anything like that.
>
> In practise we don't expect the RMM to do anything so crazy. It's not
> really clear to be whether even 2MB (PMD_SIZE) is needed. But the spec
> is written to be generic.
>
> So my current approach is to calculate the required size and pass it
> into alloc_pages_exact(). For "stupidly large" values this will fail and
> Linux just doesn't support an RMM which attempts this. If there is ever
> a usecase which needs this then we'd need to find a different method of
> providing the memory (most likely some form of carveout to avoid
> fragmentation). But my view is we should wait for that usecase to be
> identified first.
Just some comparison comments as I am also going through the TDX patches
which enable "Extension SEAMCALLs". These new SEAMCALLs are similar to
the SRO mechanism [1].
TDX asks for an upfront delegation of memory at init time using
alloc_contig_pages() that is never returned until entire module is
shutdown. alloc_contig_pages() is not subject to the MAX_ORDER limit,
but not sure that alloc_contig_pages() is suitable for small+dynamic
runtime memory add / release that SRO potentially wants to do?
Does SRO always balance the size of RMI_OP_MEM_REQ_DONATE with
RMI_OP_MEM_REQ_RECLAIM, or might some donate requests be a one way
donation like TDX? Just poking to see if there is a path to preallocate
a pool vs the fine grained per-operation alloc/free.
[1]: http://lore.kernel.org/20260522034128.3144354-3-yilun.xu@linux.intel.com
^ permalink raw reply
* Re: [PATCH 01/15] x86/virt/tdx: Read global metadata for TDX Module Extensions
From: Dan Williams (nvidia) @ 2026-06-12 22:20 UTC (permalink / raw)
To: Xu Yilun, kas, djbw, rick.p.edgecombe, x86, peter.fang
Cc: linux-coco, linux-kernel, kvm, sohil.mehta, yilun.xu, yilun.xu,
baolu.lu, zhenzhong.duan, xiaoyao.li
In-Reply-To: <20260522034128.3144354-2-yilun.xu@linux.intel.com>
Xu Yilun wrote:
> Add reading of the global metadata for TDX Module Extensions.
>
> TDX Module Extensions is an add-on feature enumerated by TDX_FEATURES0.
> But for the Module's integrity, Linux requires that all features that a
> Module advertises must have a complete, valid set of metadata, and the
> validation must succeed at core TDX initialization time.
>
> Check TDX_FEATURES0 before reading these metadata. If a feature is
> advertised, a failure in reading associated metadata causes the entire
> TDX initialization to fail, otherwise skip.
Others already commented on the patch ordering, so I will just comment
on the changelog to recommend referring back to the "any available
extension, all the time" implementation policy rather than saying "Linux
requires" which is ambiguous.
The patch reordering will make it more clear that
memory_pool_required_pages scales based on the number of features that
Linux grows enabling for at configuration time.
^ permalink raw reply
* Re: [PATCH 00/15] Enable TDX Module Extensions and DICE-based TDX Quoting
From: Dan Williams (nvidia) @ 2026-06-12 22:03 UTC (permalink / raw)
To: Xu Yilun, kas, djbw, rick.p.edgecombe, x86, peter.fang
Cc: linux-coco, linux-kernel, kvm, sohil.mehta, yilun.xu, yilun.xu,
baolu.lu, zhenzhong.duan, xiaoyao.li
In-Reply-To: <20260522034128.3144354-1-yilun.xu@linux.intel.com>
Xu Yilun wrote:
> This posting is just to collect initial review.
>
> Sean, Paolo, Dave please feel free to ignore for now. Sean, especially
> the x86 KVM stuff is only here as an example for the init code, and not
> ready for review.
>
> Kiryl and Dan, we are trying to get acks for the first 4 patches of the
> series so they can be serve as a settled base for all the other work
> that uses Extensions. Please review the first 4 patches and treat the
> later ones as an example for the Extensions initialization.
>
> == Why it's being posted ==
>
> The TDX Module is introducing a new concept called "TDX Module
> Extensions", and several upcoming features depend on them. The
> Extensions need some extra setup at TDX module init time, and the code
> to do this is expected to be somewhat generic.
>
> We want to get the basics of this TDX module extensions piece sorted so
> that all of the extension-based work can build on it. This series
> includes those basics, and an example usage called DICE-based TDX
> Quoting. Only the first 4 patches are about initializing the TDX module
> Extensions. I'd like some review on them. The later DICE patches are
> just included to serve as a usage example for the TDX module extension
> code.
>
> The first 4 patches will eventually need an ack by an x86 maintainer, so
> please review with that in mind.
>
> == Overview ==
>
> TDX Module introduces the "TDX Module Extensions" to support long
> running / hard-irq preemptible flows inside. This makes TDX Module
> capable of handling complex tasks through "Extension SEAMCALLs".
The internal implementation details of extension seamcalls buries the
lead on why this mechanism is important, why Linux should care, and why
this brings TDX in line with the other major CC architectures. Something
like:
===
To date, SEAMCALLs have been short lived routines that monopolize the
CPU for their duration. This limits their utility for implementing
higher order security protocols or pushes complexity into Linux. The
Linux appetite for ingesting complexity is low, so TDX now adds a new
class of SEAMCALLs that are preemptible and resumable. This capability
enables higher order service APIs to carry out a security protocol like
"establish an SPDM session".
The TDX "Extension SEAMCALL" capability is akin to ARM CCA's "Stateful
RMI Operations (SRO)", and achieves similar externalized complexity
relief as a dedicated hardware coprocessor like AMD SEV-SNP. The
mechanism is "give the service environment some memory", "invoke the
service API", and "continue invoking until complete". All protocol state
is internal the service API.
The simplest class of extension SEAMCALLs to support are in support of
"DICE-based TDX Quoting", a service to turn guest launch attestation
reports into a document that can be externally verified.
===
> TDX Module allows some add-on features to use the Extension. The first
> feature to use Extensions is DICE-based TDX Quoting [1]. DICE is an
> industry-standard, certificate-backed attestation framework that layers
> evidence through a chain of certificates.
>
> This series adds infrastructure to enable the Extensions and then
> implement DICE-based TDX Quoting.
>
> The Extensions consumes relatively large amount of memory (~50MB). So it
> is designed to be off by default.
This confuses the TDX design with the Linux design, and sets up "50MB" as
something to be quibbled with. The Linux design is turn on all the
features that Linux knows about all the time. Unless and until the "any
available, all the time" becomes untenable it just simplifies the init
flow to not play piecemeal games. Await evidence to change the simple
policy. Suffice to say the cost of this policy will burn 10s of
megabytes.
> It must be enabled after basic TDX
> Module initialization and when add-on features require it. To enable
> the Extensions, host first adds extra memory to TDX Module via a
> SEAMCALL (TDH.EXT.MEM.ADD), then uses another SEAMCALL (TDH.EXT.INIT) to
> initialize Extensions, and then some add-on features, e.g. DICE, could
> use Extension SEAMCALLs for work. Note that host can never get the added
> memory back.
>
> Theoretically, the Extensions doesn't need to be enabled right after
> basic TDX initialization. It could be enabled right before the first
> Extension SEAMCALL is issued. That would save or postpone memory usage.
> But it isn't worth the complexity, the needs for the Extensions are vast
> but the savings are little for a typical TDX capable system (about
> 0.001% of memory). So the Linux decision is to just enable it along with
> the basic TDX.
>
> This series has 2 distinct parts:
>
> Patches 1-4: TDX Module Extensions enabling
> Patches 5-15: DICE-based TDX Quoting, primarily Peter's work.
>
> == Some history ==
>
> The TDX Module Extensions part was first posted along with TDX
> Connect [2]. Now this part is remarkably smaller because we've removed
> the generic tdx_page_array abstraction for HPA_LIST_INFO. TDX Module
> Extensions is the first user of HPA_LIST_INFO, and doesn't use it in a
> typical way (HPA_LIST_INFO can only hold at most 2MB memory). There
> isn't enough justification to make the abstraction in this series. A
> possible plan is to rebuild tdx_page_array iteratively when more use
> cases arise.
No need to talk about details not in this series. I would maybe just
note that quoting is the simplest first consumer and was chosen as the
lead vehicle over TDX Connect previously posted in case anyone asks.
^ permalink raw reply
* RE: [RFC PATCH] mm/vmalloc: add vmalloc_decrypted() and vzalloc_decrypted()
From: Michael Kelley @ 2026-06-12 19:06 UTC (permalink / raw)
To: Jason Gunthorpe, Catalin Marinas, Christoph Hellwig
Cc: Kameron Carr, akpm@linux-foundation.org, urezki@gmail.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org, rppt@kernel.org,
Michael Kelley, linux-coco@lists.linux.dev, Suzuki K Poulose
In-Reply-To: <20260612181807.GP1066031@ziepe.ca>
From: Jason Gunthorpe <jgg@ziepe.ca> Sent: Friday, June 12, 2026 11:18 AM
>
> On Fri, Jun 12, 2026 at 06:49:28PM +0100, Catalin Marinas wrote:
> > On Thu, Jun 11, 2026 at 08:49:54AM -0300, Jason Gunthorpe wrote:
> > > On Mon, Jun 08, 2026 at 04:37:02PM +0100, Catalin Marinas wrote:
> > > > > +/**
> > > > > + * vzalloc_decrypted - allocate zeroed virtually contiguous decrypted memory
> > > > > + * @size: allocation size
> > > > > + *
> > > > > + * Like vmalloc_decrypted(), but the memory is set to zero.
> > > > > + *
> > > > > + * Return: pointer to the allocated memory or %NULL on error
> > > > > + */
> > > > > +void *vzalloc_decrypted_noprof(unsigned long size)
> > > > > +{
> > > > > + void *addr;
> > > > > +
> > > > > + addr = __vmalloc_node_range_noprof(size, 1, VMALLOC_START, VMALLOC_END,
> > > > > + GFP_KERNEL,
> > > > > + pgprot_decrypted(PAGE_KERNEL),
> > > > > + VM_DECRYPTED, NUMA_NO_NODE,
> > > > > + __builtin_return_address(0));
> > > > > + if (addr)
> > > > > + memset(addr, 0, size);
> > > >
> > > > Talking to Suzuki, the small window between set_memory_decrypted() and
> > > > memset() potentially exposing stale data is safe, at least for Arm CCA
> > > > as the memory would be scrubbed (there are other places in the kernel
> > > > where we do something similar). I assume that's also the case for other
> > > > architectures, although not sure what pKVM does.
> > >
> > > It seems like a poor practice though, this should probably be
> > > re-organized to use __GFP_ZERO so things are ordered sensibly.
> >
> > __GFP_ZERO doesn't work if the intermediate set_memory_decrypted()
> > mangles the data (e.g. changes encryption keys) and it no longer reads
> > as zeros.
>
> I thought arches are either preserving the memory content or zeroing
> it, you are saying some arch leaves it as garbage? I'd argue that's an
> arch bug and they should clear it in their path.
AMD SEV-SNP leaves the memory contents as garbage after an encryption
or decryption state change. On the flip side, my understanding has been
that TDX zeroes the memory (or at least has an option to do so) after
such a state change, though a couple of AI chats say TDX also leaves
garbage. To be sure, I'd have to run an experiment to check in a TDX
guest on Hyper-V.
>
> Otherwise this sharp edge is not documented and we have many other
> places getting it wrong, eg system_heap_allocate() doesn't re-zero the
> memory after decrypting it.
In the Hyper-V code that uses set_memory_decrypted()/encrypted(),
there's always an explicit call to set the memory to zero afterwards.
Michael
>
> > > But what is the purpose of this? I guess some hyperv thing - but
> > > shouldn't we have a more structured way to "DMA map" things for the
> > > hypervisor instead of stuff like this? Why can't you use
> > > dma_alloc_coherent() which actually gives you an address that is
> > > sensible to pass to the hypervisor?
> >
> > IIRC netvsc_init_buf() uses vzalloc() to allocate some memory and that
> > buffer ends up in set_memory_decrypted() via vmbus_establish_gpadl().
> > arm64 does not support changing the decrypted/shared attributed of
> > vmalloc mappings and I don't think we should add it. Better to just
> > allocate it properly upfront.
>
> Sure
>
> > We might be able to use the DMA API but we won't get something like
> > vmalloc() - physically non-contiguous.
>
> The entry point is dma_alloc_noncontiguous() and you get a scatterlist
> back.
>
> > I think dma_alloc_noncontiguous() just falls back to
> > dma_direct_alloc_pages() in the absence of an iommu.
>
> In all cases you get a scatterlist with a CPU list and a DMA
> list. iommu gives a smaller DMA list.
>
> If you want a vmap then you can feed that CPU page list from the sgl
> into vmap().
>
> A dma_alloc_noncontiguous_vmap() helper would not be hard to make, and
> IMHO, would make alot more sense for hyperv to treat the memory access
> from the hypervisor as "DMA" instead of trying to re-invent the DMA
> API.. :\
>
> HCH was already saying we should not be allowing drivers to use
> set_memory_decrypted() at all, and hyperv is the biggest non-core user
> right now...
>
> Jason
^ permalink raw reply
* Re: [RFC PATCH] mm/vmalloc: add vmalloc_decrypted() and vzalloc_decrypted()
From: Jason Gunthorpe @ 2026-06-12 18:18 UTC (permalink / raw)
To: Catalin Marinas, Christoph Hellwig
Cc: Kameron Carr, akpm, urezki, linux-mm, linux-kernel, rppt,
mhklinux, linux-coco, Suzuki K Poulose
In-Reply-To: <aixGqCqKkQeDfUST@arm.com>
On Fri, Jun 12, 2026 at 06:49:28PM +0100, Catalin Marinas wrote:
> On Thu, Jun 11, 2026 at 08:49:54AM -0300, Jason Gunthorpe wrote:
> > On Mon, Jun 08, 2026 at 04:37:02PM +0100, Catalin Marinas wrote:
> > > > +/**
> > > > + * vzalloc_decrypted - allocate zeroed virtually contiguous decrypted memory
> > > > + * @size: allocation size
> > > > + *
> > > > + * Like vmalloc_decrypted(), but the memory is set to zero.
> > > > + *
> > > > + * Return: pointer to the allocated memory or %NULL on error
> > > > + */
> > > > +void *vzalloc_decrypted_noprof(unsigned long size)
> > > > +{
> > > > + void *addr;
> > > > +
> > > > + addr = __vmalloc_node_range_noprof(size, 1, VMALLOC_START, VMALLOC_END,
> > > > + GFP_KERNEL,
> > > > + pgprot_decrypted(PAGE_KERNEL),
> > > > + VM_DECRYPTED, NUMA_NO_NODE,
> > > > + __builtin_return_address(0));
> > > > + if (addr)
> > > > + memset(addr, 0, size);
> > >
> > > Talking to Suzuki, the small window between set_memory_decrypted() and
> > > memset() potentially exposing stale data is safe, at least for Arm CCA
> > > as the memory would be scrubbed (there are other places in the kernel
> > > where we do something similar). I assume that's also the case for other
> > > architectures, although not sure what pKVM does.
> >
> > It seems like a poor practice though, this should probably be
> > re-organized to use __GFP_ZERO so things are ordered sensibly.
>
> __GFP_ZERO doesn't work if the intermediate set_memory_decrypted()
> mangles the data (e.g. changes encryption keys) and it no longer reads
> as zeros.
I thought arches are either preserving the memory content or zeroing
it, you are saying some arch leaves it as garbage? I'd argue that's an
arch bug and they should clear it in their path.
Otherwise this sharp edge is not documented and we have many other
places getting it wrong, eg system_heap_allocate() doesn't re-zero the
memory after decrypting it.
> > But what is the purpose of this? I guess some hyperv thing - but
> > shouldn't we have a more structured way to "DMA map" things for the
> > hypervisor instead of stuff like this? Why can't you use
> > dma_alloc_coherent() which actually gives you an address that is
> > sensible to pass to the hypervisor?
>
> IIRC netvsc_init_buf() uses vzalloc() to allocate some memory and that
> buffer ends up in set_memory_decrypted() via vmbus_establish_gpadl().
> arm64 does not support changing the decrypted/shared attributed of
> vmalloc mappings and I don't think we should add it. Better to just
> allocate it properly upfront.
Sure
> We might be able to use the DMA API but we won't get something like
> vmalloc() - physically non-contiguous.
The entry point is dma_alloc_noncontiguous() and you get a scatterlist
back.
> I think dma_alloc_noncontiguous() just falls back to
> dma_direct_alloc_pages() in the absence of an iommu.
In all cases you get a scatterlist with a CPU list and a DMA
list. iommu gives a smaller DMA list.
If you want a vmap then you can feed that CPU page list from the sgl
into vmap().
A dma_alloc_noncontiguous_vmap() helper would not be hard to make, and
IMHO, would make alot more sense for hyperv to treat the memory access
from the hypervisor as "DMA" instead of trying to re-invent the DMA
API.. :\
HCH was already saying we should not be allowing drivers to use
set_memory_decrypted() at all, and hyperv is the biggest non-core user
right now...
Jason
^ permalink raw reply
* Re: [RFC PATCH] mm/vmalloc: add vmalloc_decrypted() and vzalloc_decrypted()
From: Catalin Marinas @ 2026-06-12 17:49 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Kameron Carr, akpm, urezki, linux-mm, linux-kernel, rppt,
mhklinux, linux-coco, Suzuki K Poulose
In-Reply-To: <20260611114954.GC1066031@ziepe.ca>
On Thu, Jun 11, 2026 at 08:49:54AM -0300, Jason Gunthorpe wrote:
> On Mon, Jun 08, 2026 at 04:37:02PM +0100, Catalin Marinas wrote:
> > > +/**
> > > + * vzalloc_decrypted - allocate zeroed virtually contiguous decrypted memory
> > > + * @size: allocation size
> > > + *
> > > + * Like vmalloc_decrypted(), but the memory is set to zero.
> > > + *
> > > + * Return: pointer to the allocated memory or %NULL on error
> > > + */
> > > +void *vzalloc_decrypted_noprof(unsigned long size)
> > > +{
> > > + void *addr;
> > > +
> > > + addr = __vmalloc_node_range_noprof(size, 1, VMALLOC_START, VMALLOC_END,
> > > + GFP_KERNEL,
> > > + pgprot_decrypted(PAGE_KERNEL),
> > > + VM_DECRYPTED, NUMA_NO_NODE,
> > > + __builtin_return_address(0));
> > > + if (addr)
> > > + memset(addr, 0, size);
> >
> > Talking to Suzuki, the small window between set_memory_decrypted() and
> > memset() potentially exposing stale data is safe, at least for Arm CCA
> > as the memory would be scrubbed (there are other places in the kernel
> > where we do something similar). I assume that's also the case for other
> > architectures, although not sure what pKVM does.
>
> It seems like a poor practice though, this should probably be
> re-organized to use __GFP_ZERO so things are ordered sensibly.
__GFP_ZERO doesn't work if the intermediate set_memory_decrypted()
mangles the data (e.g. changes encryption keys) and it no longer reads
as zeros.
> But what is the purpose of this? I guess some hyperv thing - but
> shouldn't we have a more structured way to "DMA map" things for the
> hypervisor instead of stuff like this? Why can't you use
> dma_alloc_coherent() which actually gives you an address that is
> sensible to pass to the hypervisor?
IIRC netvsc_init_buf() uses vzalloc() to allocate some memory and that
buffer ends up in set_memory_decrypted() via vmbus_establish_gpadl().
arm64 does not support changing the decrypted/shared attributed of
vmalloc mappings and I don't think we should add it. Better to just
allocate it properly upfront.
We might be able to use the DMA API but we won't get something like
vmalloc() - physically non-contiguous. I think dma_alloc_noncontiguous()
just falls back to dma_direct_alloc_pages() in the absence of an iommu.
--
Catalin
^ permalink raw reply
* Re: [PATCH 1/2] x86/tdx: Add helper to query maximum TD Quote size
From: Xiaoyao Li @ 2026-06-12 14:25 UTC (permalink / raw)
To: Peter Fang, Dave Hansen, Kiryl Shutsemau, Rick Edgecombe,
Kuppuswamy Sathyanarayanan
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
H. Peter Anvin, linux-kernel, linux-coco, kvm
In-Reply-To: <20260612110853.3188196-2-peter.fang@intel.com>
On 6/12/2026 7:08 PM, Peter Fang wrote:
> TDX attestation blob ("TD Quote") sizes can grow with newer
> cryptographic schemes, so guests can no longer rely on a fixed-size
> buffer for the Quote.
>
> Newer TDX modules report the maximum TD Quote size via a TD-scope
> metadata field. Add a helper to query it instead of exposing tdg_vm_rd()
> directly, as it can read arbitrary metadata fields.
>
> Thanks to Xu Yilun for suggesting this.
>
> Assisted-by: Claude:claude-opus-4-7
> Assisted-by: GitHub Copilot:gpt-5.4
> Signed-off-by: Peter Fang <peter.fang@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
I have another nit other than Kiryl's
> ---
> arch/x86/coco/tdx/tdx.c | 19 +++++++++++++++++++
> arch/x86/include/asm/shared/tdx.h | 1 +
> arch/x86/include/asm/tdx.h | 2 ++
> 3 files changed, 22 insertions(+)
>
> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
> index 186915a17c50..88c66c46e70a 100644
> --- a/arch/x86/coco/tdx/tdx.c
> +++ b/arch/x86/coco/tdx/tdx.c
> @@ -197,6 +197,25 @@ u64 tdx_hcall_get_quote(u8 *buf, size_t size)
> }
> EXPORT_SYMBOL_GPL(tdx_hcall_get_quote);
>
> +/**
> + * tdx_get_max_quote_size() - Get the maximum TD Quote size
> + *
> + * Read the maximum size of a TD Quote from a 4-byte TD metadata field. The TDX
> + * guest driver uses it to size the buffer for Quote retrieval. Older TDX
> + * modules do not support this field and return an error.
> + *
> + * Return: Maximum Quote size in bytes on success, or 0 on failure.
> + */
> +u32 tdx_get_max_quote_size(void)
> +{
> + u64 val, ret;
> +
> + ret = tdg_vm_rd(TDCS_QUOTE_MAX_SIZE, &val);
> +
> + return ret ? 0 : (u32)val;
> +}
> +EXPORT_SYMBOL_GPL(tdx_get_max_quote_size);
Do we need to start to use
EXPORT_SYMBOL_FOR_MODULES(tdx_get_max_quote_size, "tdx-guest") ?
> +
> static void __noreturn tdx_panic(const char *msg)
> {
> struct tdx_module_args args = {
> diff --git a/arch/x86/include/asm/shared/tdx.h b/arch/x86/include/asm/shared/tdx.h
> index 049638e3da74..2880f493a8e5 100644
> --- a/arch/x86/include/asm/shared/tdx.h
> +++ b/arch/x86/include/asm/shared/tdx.h
> @@ -49,6 +49,7 @@
> /* TDX TD-Scope Metadata. To be used by TDG.VM.WR and TDG.VM.RD */
> #define TDCS_CONFIG_FLAGS 0x1110000300000016
> #define TDCS_TD_CTLS 0x1110000300000017
> +#define TDCS_QUOTE_MAX_SIZE 0x9010000200000008
> #define TDCS_NOTIFY_ENABLES 0x9100000000000010
> #define TDCS_TOPOLOGY_ENUM_CONFIGURED 0x9100000000000019
>
> diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
> index a149740b24e8..ac39674c9479 100644
> --- a/arch/x86/include/asm/tdx.h
> +++ b/arch/x86/include/asm/tdx.h
> @@ -72,6 +72,8 @@ int tdx_mcall_extend_rtmr(u8 index, u8 *data);
>
> u64 tdx_hcall_get_quote(u8 *buf, size_t size);
>
> +u32 tdx_get_max_quote_size(void);
> +
> void __init tdx_dump_attributes(u64 td_attr);
> void __init tdx_dump_td_ctls(u64 td_ctls);
>
^ permalink raw reply
* Re: [PATCH 2/2] virt: tdx-guest: Allocate Quote buffer dynamically
From: Kiryl Shutsemau @ 2026-06-12 12:37 UTC (permalink / raw)
To: Peter Fang
Cc: Dave Hansen, Rick Edgecombe, Kuppuswamy Sathyanarayanan,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
H. Peter Anvin, linux-kernel, linux-coco, kvm
In-Reply-To: <20260612110853.3188196-3-peter.fang@intel.com>
On Fri, Jun 12, 2026 at 04:08:49AM -0700, Peter Fang wrote:
> @@ -171,7 +171,7 @@ static void tdx_mr_deinit(const struct attribute_group *mr_grp)
> #define GET_QUOTE_SUCCESS 0
> #define GET_QUOTE_IN_FLIGHT 0xffffffffffffffff
>
> -#define TDX_QUOTE_MAX_LEN (GET_QUOTE_BUF_SIZE - sizeof(struct tdx_quote_buf))
> +#define TDX_QUOTE_BUF_LEN(n) (offsetof(struct tdx_quote_buf, data) + (n))
I've got confused by this offsetof(). It is valid, but why not plain
sizeof()?
Otherwise looks okay to me:
Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH 1/2] x86/tdx: Add helper to query maximum TD Quote size
From: Kiryl Shutsemau @ 2026-06-12 12:36 UTC (permalink / raw)
To: Peter Fang
Cc: Dave Hansen, Rick Edgecombe, Kuppuswamy Sathyanarayanan,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
H. Peter Anvin, linux-kernel, linux-coco, kvm
In-Reply-To: <20260612110853.3188196-2-peter.fang@intel.com>
On Fri, Jun 12, 2026 at 04:08:48AM -0700, Peter Fang wrote:
> TDX attestation blob ("TD Quote") sizes can grow with newer
> cryptographic schemes, so guests can no longer rely on a fixed-size
> buffer for the Quote.
>
> Newer TDX modules report the maximum TD Quote size via a TD-scope
> metadata field. Add a helper to query it instead of exposing tdg_vm_rd()
> directly, as it can read arbitrary metadata fields.
>
> Thanks to Xu Yilun for suggesting this.
>
> Assisted-by: Claude:claude-opus-4-7
> Assisted-by: GitHub Copilot:gpt-5.4
These supposes to be on the same line, no?
Documentation/process/coding-assistants.rst: Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
> Signed-off-by: Peter Fang <peter.fang@intel.com>
One nit below, otherwise:
Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> ---
> arch/x86/coco/tdx/tdx.c | 19 +++++++++++++++++++
> arch/x86/include/asm/shared/tdx.h | 1 +
> arch/x86/include/asm/tdx.h | 2 ++
> 3 files changed, 22 insertions(+)
>
> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
> index 186915a17c50..88c66c46e70a 100644
> --- a/arch/x86/coco/tdx/tdx.c
> +++ b/arch/x86/coco/tdx/tdx.c
> @@ -197,6 +197,25 @@ u64 tdx_hcall_get_quote(u8 *buf, size_t size)
> }
> EXPORT_SYMBOL_GPL(tdx_hcall_get_quote);
>
> +/**
> + * tdx_get_max_quote_size() - Get the maximum TD Quote size
> + *
> + * Read the maximum size of a TD Quote from a 4-byte TD metadata field. The TDX
> + * guest driver uses it to size the buffer for Quote retrieval. Older TDX
> + * modules do not support this field and return an error.
> + *
> + * Return: Maximum Quote size in bytes on success, or 0 on failure.
> + */
> +u32 tdx_get_max_quote_size(void)
> +{
> + u64 val, ret;
> +
> + ret = tdg_vm_rd(TDCS_QUOTE_MAX_SIZE, &val);
> +
> + return ret ? 0 : (u32)val;
Cast is redundant.
> +}
> +EXPORT_SYMBOL_GPL(tdx_get_max_quote_size);
> +
> static void __noreturn tdx_panic(const char *msg)
> {
> struct tdx_module_args args = {
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [RFC PATCH 0/6] Support virtio-mem memory hotplug in TDX guests
From: Kiryl Shutsemau @ 2026-06-12 12:16 UTC (permalink / raw)
To: Zhenzhong Duan
Cc: marcandre.lureau, david, rick.p.edgecombe, prsampat, pbonzini,
mst, peterx, chenyi.qiang, elena.reshetova, michaeluth,
ackerleytng, linux-kernel, linux-coco, virtualization, x86,
yilun.xu, xiaoyao.li, chao.p.peng
In-Reply-To: <20260604093551.1511079-1-zhenzhong.duan@intel.com>
On Thu, Jun 04, 2026 at 05:35:45AM -0400, Zhenzhong Duan wrote:
> 2. Re-accepting already-accepted memory returns errors. Ignoring these errors
> can mislead the guest into believing re-accepted memory is zeroed when it
> contains stale data.
Re-accepting concern is valid, but often overblown. Reaccepting memory
that never got allocated is fine.
> == About this series ==
>
> This series takes a different direction, supporting start-private memory
> and addressing the limitations of previous series [1] by implementing a
> callback-based infrastructure that integrates TDX memory acceptance and
> release operations with proper subblock granularity.
You are presenting these callbacks as generic memory hotplug thingy, but
it is only plugged into virtio mem. ACPI hotplug won't accept/release
memory unless I miss something. Are you expecting them to cover non
virtio cases too?
And these callbacks feels like very ad-hoc solution.
> See Rick and Paolo's
> discussion about using TDG.MEM.PAGE.RELEASE in [1].
Having RELEASE in hotplug path without addressing private->shared
conversion first is odd. That's the most obvious path that has to be
covered first.
Hm?
> == Future work ==
> support lazy accept
It would be nice to have some outline on how we will get there to
understand if this patchset is stepping stone or dead end that has to be
thrown away later on.
Hot[un]plug is often used to manager overcommited host. Eager accept
might be counter-productive.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* [PATCH 1/2] x86/tdx: Add helper to query maximum TD Quote size
From: Peter Fang @ 2026-06-12 11:08 UTC (permalink / raw)
To: Dave Hansen, Kiryl Shutsemau, Rick Edgecombe,
Kuppuswamy Sathyanarayanan
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
H. Peter Anvin, linux-kernel, linux-coco, kvm, Peter Fang
In-Reply-To: <20260612110853.3188196-1-peter.fang@intel.com>
TDX attestation blob ("TD Quote") sizes can grow with newer
cryptographic schemes, so guests can no longer rely on a fixed-size
buffer for the Quote.
Newer TDX modules report the maximum TD Quote size via a TD-scope
metadata field. Add a helper to query it instead of exposing tdg_vm_rd()
directly, as it can read arbitrary metadata fields.
Thanks to Xu Yilun for suggesting this.
Assisted-by: Claude:claude-opus-4-7
Assisted-by: GitHub Copilot:gpt-5.4
Signed-off-by: Peter Fang <peter.fang@intel.com>
---
arch/x86/coco/tdx/tdx.c | 19 +++++++++++++++++++
arch/x86/include/asm/shared/tdx.h | 1 +
arch/x86/include/asm/tdx.h | 2 ++
3 files changed, 22 insertions(+)
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
index 186915a17c50..88c66c46e70a 100644
--- a/arch/x86/coco/tdx/tdx.c
+++ b/arch/x86/coco/tdx/tdx.c
@@ -197,6 +197,25 @@ u64 tdx_hcall_get_quote(u8 *buf, size_t size)
}
EXPORT_SYMBOL_GPL(tdx_hcall_get_quote);
+/**
+ * tdx_get_max_quote_size() - Get the maximum TD Quote size
+ *
+ * Read the maximum size of a TD Quote from a 4-byte TD metadata field. The TDX
+ * guest driver uses it to size the buffer for Quote retrieval. Older TDX
+ * modules do not support this field and return an error.
+ *
+ * Return: Maximum Quote size in bytes on success, or 0 on failure.
+ */
+u32 tdx_get_max_quote_size(void)
+{
+ u64 val, ret;
+
+ ret = tdg_vm_rd(TDCS_QUOTE_MAX_SIZE, &val);
+
+ return ret ? 0 : (u32)val;
+}
+EXPORT_SYMBOL_GPL(tdx_get_max_quote_size);
+
static void __noreturn tdx_panic(const char *msg)
{
struct tdx_module_args args = {
diff --git a/arch/x86/include/asm/shared/tdx.h b/arch/x86/include/asm/shared/tdx.h
index 049638e3da74..2880f493a8e5 100644
--- a/arch/x86/include/asm/shared/tdx.h
+++ b/arch/x86/include/asm/shared/tdx.h
@@ -49,6 +49,7 @@
/* TDX TD-Scope Metadata. To be used by TDG.VM.WR and TDG.VM.RD */
#define TDCS_CONFIG_FLAGS 0x1110000300000016
#define TDCS_TD_CTLS 0x1110000300000017
+#define TDCS_QUOTE_MAX_SIZE 0x9010000200000008
#define TDCS_NOTIFY_ENABLES 0x9100000000000010
#define TDCS_TOPOLOGY_ENUM_CONFIGURED 0x9100000000000019
diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
index a149740b24e8..ac39674c9479 100644
--- a/arch/x86/include/asm/tdx.h
+++ b/arch/x86/include/asm/tdx.h
@@ -72,6 +72,8 @@ int tdx_mcall_extend_rtmr(u8 index, u8 *data);
u64 tdx_hcall_get_quote(u8 *buf, size_t size);
+u32 tdx_get_max_quote_size(void);
+
void __init tdx_dump_attributes(u64 td_attr);
void __init tdx_dump_td_ctls(u64 td_ctls);
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] tdx-guest: Make Quote buffer size dynamic
From: Peter Fang @ 2026-06-12 11:08 UTC (permalink / raw)
To: Dave Hansen, Kiryl Shutsemau, Rick Edgecombe,
Kuppuswamy Sathyanarayanan
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
H. Peter Anvin, linux-kernel, linux-coco, kvm, Peter Fang
Hi,
This series changes the TDX attestation driver's Quote buffer size from
a fixed constant to a value queried from the TDX module. So effectively:
s/FIXED_BUF_SIZE/queried_buf_size/g
...in the TDX guest driver.
Terminology
===========
A "TD Quote" is an attestation structure signed with a platform key. It
contains information about a TDX guest and the platform it's running on.
The "Quote buffer" in the TDX guest driver is a memory buffer shared
between the TDX guest and the host VMM to retrieve TD Quotes. It has a
header defined in the GHCI spec [1].
Device Identifier Composition Engine ("DICE") provides a framework for
layering attestation evidence. This replaces the SGX model of contacting
an Intel server to obtain a certificate.
Problem
=======
The fixed-size Quote buffer approach is not sustainable. As
cryptographic algorithms evolve, TD Quote sizes also grow. A previous
commit [2] increased the guest driver's fixed-size Quote buffer to 128
KB to accommodate DICE Quotes, but it may still be insufficient when
those Quotes use post-quantum cryptography (PQC). PQC certificate chains
are roughly 10x-15x larger than conventional ones, which can increase
Quote sizes to several megabytes.
What's in this series
=====================
To avoid changing the driver whenever the Quote buffer becomes too
small, newer TDX modules report their maximum Quote size via a metadata
field. The guest driver uses this value for its Quote buffer when
available. Older TDX modules continue to use the 128 KB buffer.
The changes do not affect configfs-tsm-report ABIs.
Patch 1/2: Add a helper to read the QUOTE_MAX_SIZE metadata field.
Patch 2/2: Replace the fixed Quote buffer size with the queried value,
when available.
AI use
======
I used AI tools (Claude:claude-opus-4-7, GitHub Copilot:gpt-5.4) to
proofread this cover letter and the changelogs. The series also
underwent AI code review (Claude:claude-opus-4-7), but the feedback was
limited to style suggestions.
[1] Guest Hypervisor Communication Interface (GHCI) Specification,
Version 1.5, Section "TDG.VP.VMCALL<GetQuote>"
[2] 43185067c6fd ("configfs-tsm-report: tdx_guest: Increase Quote buffer
size to 128KB")
Kuppuswamy Sathyanarayanan (1):
virt: tdx-guest: Allocate Quote buffer dynamically
Peter Fang (1):
x86/tdx: Add helper to query maximum TD Quote size
arch/x86/coco/tdx/tdx.c | 19 +++++++++
arch/x86/include/asm/shared/tdx.h | 1 +
arch/x86/include/asm/tdx.h | 2 +
drivers/virt/coco/tdx-guest/tdx-guest.c | 52 ++++++++++++++++++-------
4 files changed, 60 insertions(+), 14 deletions(-)
base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
--
2.53.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox