hw/tpm/tpm_crb.c | 167 +++++++++++++++++++++++++++---- include/hw/acpi/tpm.h | 5 +- tests/qtest/tpm-crb-swtpm-test.c | 10 ++ tests/qtest/tpm-util.c | 106 +++++++++++++++++--- tests/qtest/tpm-util.h | 5 + 5 files changed, 256 insertions(+), 37 deletions(-)
The move to Post Quantum Cryptography (PQC) changes how we manage memory buffers. Unlike classic crypto algorithms like RSA or ECC which used small keys and signatures, PQC algorithms require larger buffers. The new version of TCG TPM v185 (currently under review [1]) supports sending data/commands in chunks for the CRB (Command Response Buffer) interface. This is in line with the initiative to support PQC algorithms. This series implements the logic to send and receive data from the linux guest to the TPM backend in chunks, thereby allowing the guest to send larger data buffers. We introduce 2 new control registers called nextChunk and crbRspRetry that will control the START. We also add the CRB Interface Identifier called CapCRBChunk that is set to 1 indicating that the device supports chunking. The default maximum chunk/buffer size is 3968 (4096 - 128) bytes. During a send operation, the guest driver places data in the CRB buffer and signals nextChunk for each segment until the final chunk is reached. Upon receiving the START signal, QEMU appends the final chunk to its internal buffer and dispatches the complete command to the TPM backend. For responses, the backend's output is buffered. The guest consumes the first chunk once the START bit is cleared. Subsequent chunks are retrieved by the guest toggling the nextChunk bit, which advances the internal buffer offset and populates the CRB data window. For this to work, the linux guest tpm driver will also have to a) probe if CRB chunking is supported b) send data in chunks if the command length exceeds the chunk size. c) receive data in chunks by sending a nextChunk signal and accumulate. At present, VM live migration during a tpm command execution in chunks is not supported. We intend to add support for TIS interface in the future. The included test demonstrates functional correctness for standard buffer sizes. However, validation of PQC-sized payloads was performed via manual buffer-size overrides. [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf Arun Menon (5): hw/tpm: Add TPM CRB chunking fields hw/tpm: Refactor CRB_CTRL_START register access hw/tpm: Add internal buffer state for chunking hw/tpm: Implement TPM CRB chunking logic test/qtest: Add test for tpm crb chunking hw/tpm/tpm_crb.c | 167 +++++++++++++++++++++++++++---- include/hw/acpi/tpm.h | 5 +- tests/qtest/tpm-crb-swtpm-test.c | 10 ++ tests/qtest/tpm-util.c | 106 +++++++++++++++++--- tests/qtest/tpm-util.h | 5 + 5 files changed, 256 insertions(+), 37 deletions(-) -- 2.53.0
On 3/12/26 12:16 AM, Arun Menon wrote: > The move to Post Quantum Cryptography (PQC) changes how we manage > memory buffers. Unlike classic crypto algorithms like RSA or ECC which > used small keys and signatures, PQC algorithms require larger buffers. > > The new version of TCG TPM v185 (currently under review [1]) supports > sending data/commands in chunks for the CRB (Command Response Buffer) > interface. This is in line with the initiative to support PQC algorithms. > > This series implements the logic to send and receive data from the > linux guest to the TPM backend in chunks, thereby allowing the > guest to send larger data buffers. We introduce 2 new control registers > called nextChunk and crbRspRetry that will control the START. We also > add the CRB Interface Identifier called CapCRBChunk that is set to 1 > indicating that the device supports chunking. The default maximum > chunk/buffer size is 3968 (4096 - 128) bytes. > > During a send operation, the guest driver places data in the CRB buffer > and signals nextChunk for each segment until the final chunk is reached. > Upon receiving the START signal, QEMU appends the final chunk to its > internal buffer and dispatches the complete command to the TPM backend. > > For responses, the backend's output is buffered. The guest consumes the > first chunk once the START bit is cleared. Subsequent chunks are > retrieved by the guest toggling the nextChunk bit, which advances the > internal buffer offset and populates the CRB data window. > > For this to work, the linux guest tpm driver will also have to > a) probe if CRB chunking is supported > b) send data in chunks if the command length exceeds the chunk size. > c) receive data in chunks by sending a nextChunk signal and accumulate. > > At present, VM live migration during a tpm command execution in chunks > is not supported. We intend to add support for TIS interface in .. and also VM suspend/resume. Do you intend to support these? The problem will be state incompatibility with previous QEMU versions then since we now need to save the additional (bytes in the new) byte buffer(s) and possibly the new control registers' contents. Thanks for also thinking of the TIS support. I guess we will have the same issue there then with state incompatibilities even though with the TIS it should just be a matter of just using a bigger buffer. Theoretically we could write a 4096 byte buffer to the state if up to 4kb are held there and switch to a .version_id = 1 state for bigger buffer size, but then we could migrate to an older version of QEMU and find that it cannot do PQC transactions (anymore) due to older version of TIS there (I guess migration between major versions of QEMU is supported with all kinds of machines). Also, nothing will prevent one from running a PQC-enabled swtpm+libtpms with an older version of QEMU but one will find out if transactions don't succeed (assuming Linux TPM driver can handle it) because the QEMU TIS buffer is too small. > the future. > > The included test demonstrates functional correctness for standard > buffer sizes. However, validation of PQC-sized payloads was performed > via manual buffer-size overrides. > > [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf > > Arun Menon (5): > hw/tpm: Add TPM CRB chunking fields > hw/tpm: Refactor CRB_CTRL_START register access > hw/tpm: Add internal buffer state for chunking > hw/tpm: Implement TPM CRB chunking logic > test/qtest: Add test for tpm crb chunking > > hw/tpm/tpm_crb.c | 167 +++++++++++++++++++++++++++---- > include/hw/acpi/tpm.h | 5 +- > tests/qtest/tpm-crb-swtpm-test.c | 10 ++ > tests/qtest/tpm-util.c | 106 +++++++++++++++++--- > tests/qtest/tpm-util.h | 5 + > 5 files changed, 256 insertions(+), 37 deletions(-) >
Hi Stefan,
Thank you for taking a look into this.
On Thu, Mar 12, 2026 at 10:36:29AM -0400, Stefan Berger wrote:
>
>
> On 3/12/26 12:16 AM, Arun Menon wrote:
> > The move to Post Quantum Cryptography (PQC) changes how we manage
> > memory buffers. Unlike classic crypto algorithms like RSA or ECC which
> > used small keys and signatures, PQC algorithms require larger buffers.
> >
> > The new version of TCG TPM v185 (currently under review [1]) supports
> > sending data/commands in chunks for the CRB (Command Response Buffer)
> > interface. This is in line with the initiative to support PQC algorithms.
> >
> > This series implements the logic to send and receive data from the
> > linux guest to the TPM backend in chunks, thereby allowing the
> > guest to send larger data buffers. We introduce 2 new control registers
> > called nextChunk and crbRspRetry that will control the START. We also
> > add the CRB Interface Identifier called CapCRBChunk that is set to 1
> > indicating that the device supports chunking. The default maximum
> > chunk/buffer size is 3968 (4096 - 128) bytes.
> >
> > During a send operation, the guest driver places data in the CRB buffer
> > and signals nextChunk for each segment until the final chunk is reached.
> > Upon receiving the START signal, QEMU appends the final chunk to its
> > internal buffer and dispatches the complete command to the TPM backend.
> >
> > For responses, the backend's output is buffered. The guest consumes the
> > first chunk once the START bit is cleared. Subsequent chunks are
> > retrieved by the guest toggling the nextChunk bit, which advances the
> > internal buffer offset and populates the CRB data window.
> >
> > For this to work, the linux guest tpm driver will also have to
> > a) probe if CRB chunking is supported
> > b) send data in chunks if the command length exceeds the chunk size.
> > c) receive data in chunks by sending a nextChunk signal and accumulate.
> > > At present, VM live migration during a tpm command execution in chunks
> > is not supported. We intend to add support for TIS interface in
>
> .. and also VM suspend/resume. Do you intend to support these? The problem
> will be state incompatibility with previous QEMU versions then since we now
> need to save the additional (bytes in the new) byte buffer(s) and possibly
> the new control registers' contents.
Yes I would like to support suspend/resume along with migration.
And yes, I will start by saving those buffer information in the VMstate
subsection.
Also, I am working on the linux driver part. The logic is more
or less the same; 2 buffers, accumulating data, and send/receive based
on the new register bit.
>
> Thanks for also thinking of the TIS support. I guess we will have the same
> issue there then with state incompatibilities even though with the TIS it
> should just be a matter of just using a bigger buffer. Theoretically we
> could write a 4096 byte buffer to the state if up to 4kb are held there and
> switch to a .version_id = 1 state for bigger buffer size, but then we could
> migrate to an older version of QEMU and find that it cannot do PQC
> transactions (anymore) due to older version of TIS there (I guess migration
> between major versions of QEMU is supported with all kinds of machines).
> Also, nothing will prevent one from running a PQC-enabled swtpm+libtpms with
> an older version of QEMU but one will find out if transactions don't succeed
> (assuming Linux TPM driver can handle it) because the QEMU TIS buffer is too
> small.
Yes the same issue will come with TIS. Although changing the buffer size
TPM_TIS_BUFFER_MAX to 8192 (for now) would be a one liner change, but
handling the state, for migration and other cases will be tricky like
you mentioned for both crb and tis. If I understand correctly,
We need to know whether
a) swtpm OR the TPM backend supports chunking
b) does the underlying machine type of qemu suport chunking.
I am not sure if swtpm can set a capability bit if chunking is
supported. If we can do that, then QEMU can probe the backend and get
that information. But that will not be sufficient. To decide whether
chunking is actually allowed based on the underlying machine type we
might have to add a prop bool for the specific machine type.
If both of them (a and b) are true, only the linux probing will return
true for chunking. Thus linux will not send the huge buffers in the
first place, or even try to copy data in the subsections during
migration with the .needed function.
Please correct me if I am wrong.
>
> > the future.
> >
> > The included test demonstrates functional correctness for standard
> > buffer sizes. However, validation of PQC-sized payloads was performed
> > via manual buffer-size overrides.
> > > [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf
> >
> > Arun Menon (5):
> > hw/tpm: Add TPM CRB chunking fields
> > hw/tpm: Refactor CRB_CTRL_START register access
> > hw/tpm: Add internal buffer state for chunking
> > hw/tpm: Implement TPM CRB chunking logic
> > test/qtest: Add test for tpm crb chunking
> >
> > hw/tpm/tpm_crb.c | 167 +++++++++++++++++++++++++++----
> > include/hw/acpi/tpm.h | 5 +-
> > tests/qtest/tpm-crb-swtpm-test.c | 10 ++
> > tests/qtest/tpm-util.c | 106 +++++++++++++++++---
> > tests/qtest/tpm-util.h | 5 +
> > 5 files changed, 256 insertions(+), 37 deletions(-)
> >
>
>
Regards,
Arun Menon
On 3/13/26 3:35 PM, Arun Menon wrote: > Hi Stefan, > Thank you for taking a look into this. > > On Thu, Mar 12, 2026 at 10:36:29AM -0400, Stefan Berger wrote: >> >> >> On 3/12/26 12:16 AM, Arun Menon wrote: >>> The move to Post Quantum Cryptography (PQC) changes how we manage >>> memory buffers. Unlike classic crypto algorithms like RSA or ECC which >>> used small keys and signatures, PQC algorithms require larger buffers. >>> >>> The new version of TCG TPM v185 (currently under review [1]) supports >>> sending data/commands in chunks for the CRB (Command Response Buffer) >>> interface. This is in line with the initiative to support PQC algorithms. >>> >>> This series implements the logic to send and receive data from the >>> linux guest to the TPM backend in chunks, thereby allowing the >>> guest to send larger data buffers. We introduce 2 new control registers >>> called nextChunk and crbRspRetry that will control the START. We also >>> add the CRB Interface Identifier called CapCRBChunk that is set to 1 >>> indicating that the device supports chunking. The default maximum >>> chunk/buffer size is 3968 (4096 - 128) bytes. >>> >>> During a send operation, the guest driver places data in the CRB buffer >>> and signals nextChunk for each segment until the final chunk is reached. >>> Upon receiving the START signal, QEMU appends the final chunk to its >>> internal buffer and dispatches the complete command to the TPM backend. >>> >>> For responses, the backend's output is buffered. The guest consumes the >>> first chunk once the START bit is cleared. Subsequent chunks are >>> retrieved by the guest toggling the nextChunk bit, which advances the >>> internal buffer offset and populates the CRB data window. >>> >>> For this to work, the linux guest tpm driver will also have to >>> a) probe if CRB chunking is supported >>> b) send data in chunks if the command length exceeds the chunk size. >>> c) receive data in chunks by sending a nextChunk signal and accumulate. >>>> At present, VM live migration during a tpm command execution in chunks >>> is not supported. We intend to add support for TIS interface in >> >> .. and also VM suspend/resume. Do you intend to support these? The problem >> will be state incompatibility with previous QEMU versions then since we now >> need to save the additional (bytes in the new) byte buffer(s) and possibly >> the new control registers' contents. > > Yes I would like to support suspend/resume along with migration. > And yes, I will start by saving those buffer information in the VMstate > subsection. If we bump up the version from state v0 to v1, can v0 capable devices still read the state and discard data that are for v1? I am not sure whether the following is possible - the is maintaining backwards compatibility as much as possible: - if the CRB OS driver never touched the chunking during the transaction, write v0 state - if the CRB OS driver touched the chunking feature during the transaction, write v1 state I was looking whether we can still use qemu_put_byte() etc. but was missing the .save interface from DeviceClass for example. > > Also, I am working on the linux driver part. The logic is more > or less the same; 2 buffers, accumulating data, and send/receive based > on the new register bit. > >> >> Thanks for also thinking of the TIS support. I guess we will have the same >> issue there then with state incompatibilities even though with the TIS it >> should just be a matter of just using a bigger buffer. Theoretically we >> could write a 4096 byte buffer to the state if up to 4kb are held there and >> switch to a .version_id = 1 state for bigger buffer size, but then we could >> migrate to an older version of QEMU and find that it cannot do PQC >> transactions (anymore) due to older version of TIS there (I guess migration >> between major versions of QEMU is supported with all kinds of machines). >> Also, nothing will prevent one from running a PQC-enabled swtpm+libtpms with >> an older version of QEMU but one will find out if transactions don't succeed >> (assuming Linux TPM driver can handle it) because the QEMU TIS buffer is too >> small. > > Yes the same issue will come with TIS. Although changing the buffer size > TPM_TIS_BUFFER_MAX to 8192 (for now) would be a one liner change, but > handling the state, for migration and other cases will be tricky like > you mentioned for both crb and tis. If I understand correctly, > We need to know whether > a) swtpm OR the TPM backend supports chunking I am collecting these buffer-related issue here considering combinations of different versions of libtpms, swtpm, and QEMU (not considering Linux driver). The table is probably the best for now to see the problematic combinations on the lower layers: https://github.com/stefanberger/swtpm/issues/1076 > b) does the underlying machine type of qemu suport chunking. > > I am not sure if swtpm can set a capability bit if chunking is > supported. If we can do that, then QEMU can probe the backend and get swtpm (v0.11 and via backport also v0.10.x) will simply work with a 8kb buffer once libtpms (v0.11) tells it that it can support up to 8 kb buffers. > that information. But that will not be sufficient. To decide whether > chunking is actually allowed based on the underlying machine type we > might have to add a prop bool for the specific machine type. > Are you referring the CRB capability bit that advertises the chunking capability? I think a good sign that chunking should be supported by CRB (set the chunking-supported bit CapCRBChunk) is that the buffer queried for from swtpm indicates > 4kb (s->be_buffer_size = tpm_backend_get_buffer_size(s->tpmbe) ). If the buffer size is still 4kb it probably should not advertise the chunking capability -- hadn't thought of this while reviewing the patches, but ... you may want to add this in the code. > If both of them (a and b) are true, only the linux probing will return > true for chunking. Thus linux will not send the huge buffers in the > first place, or even try to copy data in the subsections during > migration with the .needed function. > > Please correct me if I am wrong. I am not sure about all the details yet, either. > > >> >>> the future. >>> >>> The included test demonstrates functional correctness for standard >>> buffer sizes. However, validation of PQC-sized payloads was performed >>> via manual buffer-size overrides. >>>> [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf >>> >>> Arun Menon (5): >>> hw/tpm: Add TPM CRB chunking fields >>> hw/tpm: Refactor CRB_CTRL_START register access >>> hw/tpm: Add internal buffer state for chunking >>> hw/tpm: Implement TPM CRB chunking logic >>> test/qtest: Add test for tpm crb chunking >>> >>> hw/tpm/tpm_crb.c | 167 +++++++++++++++++++++++++++---- >>> include/hw/acpi/tpm.h | 5 +- >>> tests/qtest/tpm-crb-swtpm-test.c | 10 ++ >>> tests/qtest/tpm-util.c | 106 +++++++++++++++++--- >>> tests/qtest/tpm-util.h | 5 + >>> 5 files changed, 256 insertions(+), 37 deletions(-) >>> >> >> > > Regards, > Arun Menon >
Hi Stefan, Sorry for the late response. On Fri, Mar 13, 2026 at 05:06:16PM -0400, Stefan Berger wrote: > > > On 3/13/26 3:35 PM, Arun Menon wrote: > > Hi Stefan, > > Thank you for taking a look into this. > > > > On Thu, Mar 12, 2026 at 10:36:29AM -0400, Stefan Berger wrote: > > > > > > > > > On 3/12/26 12:16 AM, Arun Menon wrote: > > > > The move to Post Quantum Cryptography (PQC) changes how we manage > > > > memory buffers. Unlike classic crypto algorithms like RSA or ECC which > > > > used small keys and signatures, PQC algorithms require larger buffers. > > > > > > > > The new version of TCG TPM v185 (currently under review [1]) supports > > > > sending data/commands in chunks for the CRB (Command Response Buffer) > > > > interface. This is in line with the initiative to support PQC algorithms. > > > > > > > > This series implements the logic to send and receive data from the > > > > linux guest to the TPM backend in chunks, thereby allowing the > > > > guest to send larger data buffers. We introduce 2 new control registers > > > > called nextChunk and crbRspRetry that will control the START. We also > > > > add the CRB Interface Identifier called CapCRBChunk that is set to 1 > > > > indicating that the device supports chunking. The default maximum > > > > chunk/buffer size is 3968 (4096 - 128) bytes. > > > > > > > > During a send operation, the guest driver places data in the CRB buffer > > > > and signals nextChunk for each segment until the final chunk is reached. > > > > Upon receiving the START signal, QEMU appends the final chunk to its > > > > internal buffer and dispatches the complete command to the TPM backend. > > > > > > > > For responses, the backend's output is buffered. The guest consumes the > > > > first chunk once the START bit is cleared. Subsequent chunks are > > > > retrieved by the guest toggling the nextChunk bit, which advances the > > > > internal buffer offset and populates the CRB data window. > > > > > > > > For this to work, the linux guest tpm driver will also have to > > > > a) probe if CRB chunking is supported > > > > b) send data in chunks if the command length exceeds the chunk size. > > > > c) receive data in chunks by sending a nextChunk signal and accumulate. > > > > > At present, VM live migration during a tpm command execution in chunks > > > > is not supported. We intend to add support for TIS interface in > > > > > > .. and also VM suspend/resume. Do you intend to support these? The problem > > > will be state incompatibility with previous QEMU versions then since we now > > > need to save the additional (bytes in the new) byte buffer(s) and possibly > > > the new control registers' contents. > > > > Yes I would like to support suspend/resume along with migration. > > And yes, I will start by saving those buffer information in the VMstate > > subsection. > > If we bump up the version from state v0 to v1, can v0 capable devices still > read the state and discard data that are for v1? > > I am not sure whether the following is possible - the is maintaining > backwards compatibility as much as possible: > - if the CRB OS driver never touched the chunking during the transaction, > write v0 state > - if the CRB OS driver touched the chunking feature during the transaction, > write v1 state > > I was looking whether we can still use qemu_put_byte() etc. but was missing > the .save interface from DeviceClass for example. In v2 of this series, I have added support for migration. I was not able to test it thoroughly because of the nature of the case we are aiming to incorporate. I think backwards compatibility is maintained by adding an entry to the hw_compat array. I am no expert, therefore I feel its best to ask someone who understands migration well. @peterx@redhat.com ? https://www.qemu.org/docs/master/devel/migration/compatibility.html#how-backwards-compatibility-works If the user starts a new qemu instance with an older machine type, then the new feature will not be enabled at all due to this flag, allowing the user to migrate to an older qemu binary while keeping the same machine type. The subsection will not be sent at all. > > > > > Also, I am working on the linux driver part. The logic is more > > or less the same; 2 buffers, accumulating data, and send/receive based > > on the new register bit. > > > > > > > > Thanks for also thinking of the TIS support. I guess we will have the same > > > issue there then with state incompatibilities even though with the TIS it > > > should just be a matter of just using a bigger buffer. Theoretically we > > > could write a 4096 byte buffer to the state if up to 4kb are held there and > > > switch to a .version_id = 1 state for bigger buffer size, but then we could > > > migrate to an older version of QEMU and find that it cannot do PQC > > > transactions (anymore) due to older version of TIS there (I guess migration > > > between major versions of QEMU is supported with all kinds of machines). > > > Also, nothing will prevent one from running a PQC-enabled swtpm+libtpms with > > > an older version of QEMU but one will find out if transactions don't succeed > > > (assuming Linux TPM driver can handle it) because the QEMU TIS buffer is too > > > small. > > > > Yes the same issue will come with TIS. Although changing the buffer size > > TPM_TIS_BUFFER_MAX to 8192 (for now) would be a one liner change, but > > handling the state, for migration and other cases will be tricky like > > you mentioned for both crb and tis. If I understand correctly, > > We need to know whether > > a) swtpm OR the TPM backend supports chunking > > I am collecting these buffer-related issue here considering combinations of > different versions of libtpms, swtpm, and QEMU (not considering Linux > driver). The table is probably the best for now to see the problematic > combinations on the lower layers: > > https://github.com/stefanberger/swtpm/issues/1076 Thank you for this nice list. > > > b) does the underlying machine type of qemu suport chunking. > > > > I am not sure if swtpm can set a capability bit if chunking is > > supported. If we can do that, then QEMU can probe the backend and get > > swtpm (v0.11 and via backport also v0.10.x) will simply work with a 8kb > buffer once libtpms (v0.11) tells it that it can support up to 8 kb buffers. > > > that information. But that will not be sufficient. To decide whether > > chunking is actually allowed based on the underlying machine type we > > might have to add a prop bool for the specific machine type. > > > > Are you referring the CRB capability bit that advertises the chunking > capability? I think a good sign that chunking should be supported by CRB > (set the chunking-supported bit CapCRBChunk) is that the buffer queried for > from swtpm indicates > 4kb (s->be_buffer_size = > tpm_backend_get_buffer_size(s->tpmbe) ). If the buffer size is still 4kb it > probably should not advertise the chunking capability -- hadn't thought of > this while reviewing the patches, but ... you may want to add this in the > code. > At the moment the new qemu binary simply sets the capability to be true by default. I missed this in v2; I shall add it to tpm_crb_reset() or tpm_crb_realize() when i post non RFC version. > > If both of them (a and b) are true, only the linux probing will return > > true for chunking. Thus linux will not send the huge buffers in the > > first place, or even try to copy data in the subsections during > > migration with the .needed function. > > > > Please correct me if I am wrong. > > I am not sure about all the details yet, either. > > > > > > > > > > > > the future. > > > > > > > > The included test demonstrates functional correctness for standard > > > > buffer sizes. However, validation of PQC-sized payloads was performed > > > > via manual buffer-size overrides. > > > > > [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf > > > > > > > > Arun Menon (5): > > > > hw/tpm: Add TPM CRB chunking fields > > > > hw/tpm: Refactor CRB_CTRL_START register access > > > > hw/tpm: Add internal buffer state for chunking > > > > hw/tpm: Implement TPM CRB chunking logic > > > > test/qtest: Add test for tpm crb chunking > > > > > > > > hw/tpm/tpm_crb.c | 167 +++++++++++++++++++++++++++---- > > > > include/hw/acpi/tpm.h | 5 +- > > > > tests/qtest/tpm-crb-swtpm-test.c | 10 ++ > > > > tests/qtest/tpm-util.c | 106 +++++++++++++++++--- > > > > tests/qtest/tpm-util.h | 5 + > > > > 5 files changed, 256 insertions(+), 37 deletions(-) > > > > > > > > > > > > > > Regards, > > Arun Menon > > > > Regards, Arun Menon
© 2016 - 2026 Red Hat, Inc.