Re: [PATCH v2 08/17] x86/virt/tdx: Prepare Quote buffer during extension bringup

[Peter Fang]

On Wed, Jul 01, 2026 at 12:56:19PM -0700, Dave Hansen wrote:
> On 6/18/26 01:13, Xu Yilun wrote:
> > For simplicity, let all guests share a global buffer. Build the buffer's
> > HPA_LINKED_LIST at Quoting extension bringup. This saves a bunch of
> > va-to-pa conversions at runtime.
> 
> va-to-pa conversions are not expensive. Even for vmalloc() memory.If
> 
> I don't like the global buffer. It just generally seems like a bad idea.
> It needs locking, it wastes memory when nobody is doing quotes, etc..
> 
> Is there a way to do this without vmalloc()?
> 
> Could userspace provide the memory and then the kernel just does a gup
> to keep it in place while the TDX module is writing to it? Or, could it
> just be allocated:

Hi Dave,

The GUP idea makes a lot of sense at a high level I think. However, the
shared buffer used by the GHCI call is not 4K-aligned because it has a
header in front of it, while the SEAMCALL expects 4K-aligned HPAs
(lesson learned...). This memory does come from userspace though:

        struct tdx_quote_req {  <-- 4K-aligned
                u64 version;
                u64 status;
                u32 in_len;
                u32 out_len;
                u8 data[];      <-- shared buffer
        };


So perhaps the simplest thing here is to just allocate a kernel buffer
before the SEAMCALL. There's also another subtle wrinkle here: KVM is
shifting from a FOLL_PIN-based API to an MMU-notifier-based API for
guest page accesses [1], so I think that means more complex code to talk
to the TDX module.

> 
> 	void *buffer = vmalloc(size);
> 	mutex_lock();
> 	// talk to TDX module
> 	mutex_unlock();
> 	vfree(buffer);
> 
> 	return ret;
> 
> That actually has some nice properties. It doesn't require locking for
> the buffer. It also penalizes folks doing lots of quotes. If you hammer
> on quoting, you hammer on the memory allocator and TLB flushing code and
> slow yourself down more. If you hammer on it from multiple threads, it
> gets even worse.
> 
> That seems like a feature not a bug.

This is a really good point... I'm a bit worried about the global impact
of vfree() though. IIUC it eventually triggers an all-CPU TLB shootdown,
so a guest abusing this path would not only throttle itself, but could
also hurt everyone else. This might be more useful if the buffer was
allocated in userspace? A free() in userspace usually triggers a more
limited TLB shootdown.

I think I can use alloc_pages_bulk() instead to avoid the TLB shootdown
cost altogether. It's a bit more work in KVM, but maybe worth it...

Thanks,
Peter

[1] https://lore.kernel.org/kvm/20211115165030.7422-8-dwmw2@xxxxxxxxxxxxx/