Re: [PATCH] tpm: Dynamically allocate tpm-tis buffer

[Arun Menon <armenon@redhat.com>]

Hi Stefan,

On Wed, Apr 29, 2026 at 02:15:16PM -0400, Stefan Berger wrote:
> 
> 
> On 4/28/26 8:57 AM, Stefan Berger wrote:
> > 
> > 
> > On 4/28/26 3:01 AM, Arun Menon wrote:
> 
> > > > 
> > > > With MAX() it can now be bigger than TPM_TIS_BUFFER_MAX if the
> > > > backend says
> > > > so -- hm...
> > > 
> > > TPM_TIS_BUFFER_MAX is still 4096.
> > 
> > Oh, I had still based my patches on your TPM_TIS_BUFFER_MAX increase to
> > 8192 bytes. Let me fixes this along with a few other things. I will let
> > you know.
> > 
> > I have another series that I will post now that can be applied to
> > master. It's adding a test for TIS over I2C but I will need to extend
> > that one also with the large transfer test case then.
> > 
> > 
> 
> So I have resolved this issue now along with a few other things. My branch
> is here: https://github.com/stefanberger/qemu-tpm/tree/work-tpm-for-11.1
> 
> - I have applied the i2c swtpm test case series first since it could be
> easily upstreamed first
> - Then your patch "migration/vmstate: Add VMState support for GByteArray"
> - Then the CRB chunk + TIS extended buffer support series. I modified my
> patches (last 4 in that series) to
>   - increased MAX_TIS_BUFFER_SIZE to 8192
>   - added migration blockers dynamically for TIS whenever >4096 bytes are
> either in the request or response; remove them later on again when device
> goes into ready state for example
>   - added large transfer test also for i2c
> 
> Please pick up those patches for v6 posting, or otherwise you can split your
> v5 series up into CRB-only support for v6 and I post my (last 4) patches
> later on.
>

Thank you. I agree. I will post v6 as CRB-only support. The GByteArray
patch is already accepted. The complex TIS changes can be posted
separately later.

Regarding the TIS buffer: I saw you implemented the migration blockers
and 8192-byte increase in your branch. Should I discard my
'Dynamically allocate tpm-tis buffer' patch entirely, or do you want to
try and adapt that logic into your TIS follow-up series later?

Since your new migration blockers are based on the 4096/8192 threshold,
it might be simpler to stick with the static approach for now, but let
me know what you prefer.


Regards,
Arun Menon

>