On Fri, Jan 17, 2020 at 05:46:21PM +0400, Marc-André Lureau wrote:
> On Fri, Jan 17, 2020 at 5:41 PM Stefan Berger <stef...@linux.ibm.com> wrote:
> >
> > On 1/17/20 8:31 AM, Marc-André Lureau wrote:
> > > Hi
> > >
> > > On Wed, Jan 8, 2020 at 8:14 PM Stefan Berger <stef...@linux.ibm.com>
> > > wrote:
> > >> From: Stefan Berger <stef...@linux.vnet.ibm.com>
> > >>
> > >> Extend the tpm_spapr frontend with VM suspend and resume support.
> > >>
> > >> Signed-off-by: Stefan Berger <stef...@linux.vnet.ibm.com>
> > >> ---
> > >> hw/tpm/tpm_spapr.c | 67 ++++++++++++++++++++++++++++++++++++++++++++-
> > >> hw/tpm/trace-events | 2 ++
> > >> 2 files changed, 68 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/hw/tpm/tpm_spapr.c b/hw/tpm/tpm_spapr.c
> > >> index ab184fbb82..cf5c7851e7 100644
> > >> --- a/hw/tpm/tpm_spapr.c
> > >> +++ b/hw/tpm/tpm_spapr.c
> > >> @@ -76,6 +76,9 @@ typedef struct {
> > >>
> > >> unsigned char buffer[TPM_SPAPR_BUFFER_MAX];
> > >>
> > >> + uint32_t numbytes; /* number of bytes in suspend_buffer */
> > >> + unsigned char *suspend_buffer;
> > > Why do you need a copy suspend_buffer? Why not use and save buffer[]
> > > directly?
> >
> >
> > This addresses David's comment:
> >
> > "Transferring the whole 4kiB buffer unconditionally when it mostly
> > won't have anything useful in it doesn't seem like a great idea."
> >
> > https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg02601.html
>
> Oh ok.. (well really I don't think 4k (usually compressed) will really
> matter much in multi-gigabytes streams ;)
Probably not - though it is in the downtime portion of the stream.
But more to the point you can still make the size / whether you send
conditional on numbytes without having a whole separate buffer for it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
