On 4/29/26 4:07 PM, Arun Menon wrote:
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
It's quite dynamic with the blocker being set when 4097 bytes of a TPM
command were received or when a TPM response with > 4096 bytes is
received. The blocker is removed when the device goes into ready state.
The intention is to allow a user to choose an old machine type with a
PQC-enabled swtpm+libtpms and be able to migrate to an older version of
QEMU unless the blocker was set. Correct me if I am wrong in my thinking...
'Dynamically allocate tpm-tis buffer' patch entirely, or do you want to
try and adapt that logic into your TIS follow-up series later?
It may be good to have a dynamically allocate tpm-tis buffer for future
proofing the TIS, though it would have to support saving a range of the
bytes in this buffer -- like 1:1 replacement using GByteArray for the
VMSTATE_PARTIAL_BUFFER and VMSTATE_BUFFER_START_MIDDLE that I am using now.
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.
It would still be good not to have to worry about buffer size increases
anymore...
Regards,
Arun Menon
