All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc: marcandre.lureau@redhat.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH v5 3/5] tpm_spapr: Support suspend and resume
Date: Fri, 13 Dec 2019 07:46:44 -0500	[thread overview]
Message-ID: <3ee5443f-6156-62de-d70d-13b4b224c2f3@linux.ibm.com> (raw)
In-Reply-To: <20191213053933.GE207300@umbus.fritz.box>

On 12/13/19 12:39 AM, David Gibson wrote:
> On Thu, Dec 12, 2019 at 03:24:28PM -0500, Stefan Berger wrote:
>> Extend the tpm_spapr frontend with VM suspend and resume support.
>>
>> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>>
>> diff --git a/hw/tpm/tpm_spapr.c b/hw/tpm/tpm_spapr.c
>> index c4a67e2403..8f5a142bd4 100644
>> --- a/hw/tpm/tpm_spapr.c
>> +++ b/hw/tpm/tpm_spapr.c
>> @@ -87,6 +87,8 @@ typedef struct {
>>       TPMVersion be_tpm_version;
>>   
>>       size_t be_buffer_size;
>> +
>> +    bool deliver_response; /* whether to deliver response after VM resume */
>>   } SPAPRvTPMState;
>>   
>>   static void tpm_spapr_show_buffer(const unsigned char *buffer,
>> @@ -256,6 +258,12 @@ static void tpm_spapr_request_completed(TPMIf *ti, int ret)
>>       uint32_t len;
>>       int rc;
>>   
>> +    if (runstate_check(RUN_STATE_FINISH_MIGRATE)) {
> I'm trying to figure out the circumstances in which
> request_completed() would get called before post_load on the
> destination.


This is on the source side where we must not deliver the response in 
case the devices are now suspending but defer the delivery to after the 
resume.


>
>> +        /* defer delivery of response until .post_load */
>> +        s->deliver_response |= true;
> |= is a bitwise OR which is not what you want, although it will
> *probably* work in practice.  Better to just use
> 	s->deliver_response = true;
>
>> +        return;
>> +    }
>> +
>>       s->state = SPAPR_VTPM_STATE_COMPLETION;
>>   
>>       /* a max. of be_buffer_size bytes can be transported */
>> @@ -316,6 +324,7 @@ static void tpm_spapr_reset(SpaprVioDevice *dev)
>>       SPAPRvTPMState *s = VIO_SPAPR_VTPM(dev);
>>   
>>       s->state = SPAPR_VTPM_STATE_NONE;
>> +    s->deliver_response = false;
>>   
>>       s->be_tpm_version = tpm_backend_get_tpm_version(s->be_driver);
>>       tpm_spapr_update_deviceclass(dev);
>> @@ -339,9 +348,53 @@ static enum TPMVersion tpm_spapr_get_version(TPMIf *ti)
>>       return tpm_backend_get_tpm_version(s->be_driver);
>>   }
>>   
>> +/* persistent state handling */
>> +
>> +static int tpm_spapr_pre_save(void *opaque)
>> +{
>> +    SPAPRvTPMState *s = opaque;
>> +
>> +    s->deliver_response |= tpm_backend_finish_sync(s->be_driver);
> Same problem here.
>
>> +    trace_tpm_spapr_pre_save(s->deliver_response);
>> +    /*
>> +     * we cannot deliver the results to the VM since DMA would touch VM memory
>> +     */
>> +
>> +    return 0;
>> +}
>> +
>> +static int tpm_spapr_post_load(void *opaque, int version_id)
>> +{
>> +    SPAPRvTPMState *s = opaque;
>> +
>> +    if (s->deliver_response) {
>> +        trace_tpm_spapr_post_load();
>> +        /* deliver the results to the VM via DMA */
>> +        tpm_spapr_request_completed(TPM_IF(s), 0);
>> +        s->deliver_response = false;
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>>   static const VMStateDescription vmstate_spapr_vtpm = {
>>       .name = "tpm-spapr",
>> -    .unmigratable = 1,
>> +    .version_id = 1,
>> +    .minimum_version_id = 0,
>> +    .minimum_version_id_old = 0,
>> +    .pre_save = tpm_spapr_pre_save,
>> +    .post_load = tpm_spapr_post_load,
>> +    .fields = (VMStateField[]) {
>> +        VMSTATE_SPAPR_VIO(vdev, SPAPRvTPMState),
>> +
>> +        VMSTATE_UINT8(state, SPAPRvTPMState),
>> +        VMSTATE_BUFFER(buffer, SPAPRvTPMState),
> Transferring the whole 4kiB buffer unconditionally when it mostly
> won't have anything useful in it doesn't seem like a great idea.


It's really only needed in case of a 'delayed response'. So, yeah, we 
could transfer data in only that case then.


>
>> +        /* remember DMA address */
>> +        VMSTATE_UINT32(crq.s.data, SPAPRvTPMState),
>> +        VMSTATE_BOOL(deliver_response, SPAPRvTPMState),
>> +        VMSTATE_END_OF_LIST(),
>> +    }
>>   };
>>   
>>   static Property tpm_spapr_properties[] = {
>> diff --git a/hw/tpm/trace-events b/hw/tpm/trace-events
>> index 6278a39618..d109661b96 100644
>> --- a/hw/tpm/trace-events
>> +++ b/hw/tpm/trace-events
>> @@ -67,3 +67,5 @@ tpm_spapr_do_crq_get_version(uint32_t version) "response: version %u"
>>   tpm_spapr_do_crq_prepare_to_suspend(void) "response: preparing to suspend"
>>   tpm_spapr_do_crq_unknown_msg_type(uint8_t type) "Unknown message type 0x%02x"
>>   tpm_spapr_do_crq_unknown_crq(uint8_t raw1, uint8_t raw2) "unknown CRQ 0x%02x 0x%02x ..."
>> +tpm_spapr_pre_save(bool v) "TPM response to deliver after resume: %d"
>> +tpm_spapr_post_load(void) "Delivering TPM response after resume"




  reply	other threads:[~2019-12-13 21:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-12 20:24 [PATCH v5 0/5] Add vTPM emulator support for ppc64 platform Stefan Berger
2019-12-12 20:24 ` [PATCH v5 1/5] tpm_spapr: Support TPM for ppc64 using CRQ based interface Stefan Berger
2019-12-12 20:33   ` Eric Blake
2019-12-12 20:34     ` Stefan Berger
2019-12-13  5:34   ` David Gibson
2019-12-13 13:03     ` Stefan Berger
2019-12-17  0:29       ` David Gibson
2019-12-17 19:44         ` Stefan Berger
2019-12-19  1:54           ` David Gibson
2019-12-19  1:59             ` Stefan Berger
2019-12-19  5:13               ` David Gibson
2019-12-19  5:14                 ` David Gibson
2019-12-12 20:24 ` [PATCH v5 2/5] tpm: Return bool from tpm_backend_finish_sync Stefan Berger
2019-12-12 20:24 ` [PATCH v5 3/5] tpm_spapr: Support suspend and resume Stefan Berger
2019-12-13  5:39   ` David Gibson
2019-12-13 12:46     ` Stefan Berger [this message]
2019-12-17  0:53       ` David Gibson
2019-12-12 20:24 ` [PATCH v5 4/5] hw/ppc/Kconfig: Enable TPM_SPAPR as part of PSERIES config Stefan Berger
2019-12-12 20:24 ` [PATCH v5 5/5] docs: tpm: Add example command line for ppc64 and tpm-spapr Stefan Berger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ee5443f-6156-62de-d70d-13b4b224c2f3@linux.ibm.com \
    --to=stefanb@linux.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=marcandre.lureau@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=stefanb@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.