Re: [PATCH v5 5/6] x86/tdx: Add a helper to query maximum Quote size

[Dave Hansen <dave.hansen@intel.com>]

On 9/29/26 02:18, Peter Fang wrote:
> On Mon, Sep 28, 2026 at 01:32:06PM -0700, Kuppuswamy Sathyanarayanan wrote:
>> On 9/28/2026 3:08 AM, Peter Fang wrote:
>>> TDX attestation report ("Quote") sizes can grow with newer crypto
>>> algorithms, so guests can no longer rely on a fixed-size buffer for the
>>> Quote.
>>>
>>> The TDX module added a new ABI that reports the largest possible Quote
>>> size via a metadata field [1]. Add a helper to query the size instead of
>>> exposing tdg_vm_rd() directly, as it can read arbitrary metadata fields.
>>>
>>> The reported size covers every Quote type the platform can produce,
>>> including SGX-based Quotes.
>>>
>>> Thanks to Xu Yilun for suggesting this in an off-list discussion.
>>
>> If the patch is suggested by Xu Uilun you can use Suggested-by:
> 
> I think tip's preference is to use some prose rather than a tag for
> these things [1]. So I'll probably keep the prose unless you have
> objections?
> 
> [1] https://lore.kernel.org/all/c1c9bddf-1c00-4625-a915-d545acd67fd0@intel.com/

Actually, I'm not a huge fan of the prose in this case either.
"Suggesting this" is not specific. What's the point of even mentioning it?

Responding to a minor review comment does not need to get documented,
either in prose or in a tag. What part of the suggestion was so
important that it needs to be remembered for all time as coming from Xu
Yilun in the commit log?

It doesn't seem that important because I don't even see Xu Yilun on cc. ;)

>>> +/*
>>> + * Ask the TDX module what the largest possible Quote might be.
>>> + */
>>> +int tdx_get_max_quote_size(u64 *max_quote_size)
>>> +{
>>> +	u64 err;
>>> +
>>> +	err = tdg_vm_rd(TDCS_QUOTE_MAX_SIZE, max_quote_size);
>>> +
>>> +	/* Old modules do not support this. Tell the caller. */
>>> +	if (err)
>>> +		return -EINVAL;
>>
>> I think -ENODEV or -EOPNOTSUPP is more appropriate return value
>> for unsupported case.
> 
> Hmm, I don't see either one being a common pattern for guest-side TDX
> code. -ENODEV is usually used for some basic operation failure.
> -EOPNOTSUPP is not used in the guest. But between the two I think
> -EOPNOTSUPP probably fits better. Thanks.

Just leave it alone. All that matters is that it is non-zero. If it were
going out to userspace, we could argue all day about it, but it's not.