Re: [Qemu-devel] [PATCH v3 0/3] TPM NVRAM persistent storage

[Anthony Liguori <aliguori@us.ibm.com>]

Corey Bryant <coreyb@linux.vnet.ibm.com> writes:

> On 06/14/2013 11:56 AM, Anthony Liguori wrote:
>> Corey Bryant <coreyb@linux.vnet.ibm.com> writes:
>>
>>> On 06/14/2013 11:38 AM, Anthony Liguori wrote:
>>>> Corey Bryant <coreyb@linux.vnet.ibm.com> writes:
>>>>
>>>>> On 06/14/2013 10:01 AM, Anthony Liguori wrote:
>>>>>> Corey Bryant <coreyb@linux.vnet.ibm.com> writes:
>>>>>>
>>>>>>> This patch series provides persistent storage support that a TPM
>>>>>>> can use to store NVRAM data.  It uses QEMU's block driver to store
>>>>>>> data on a drive image.  The libtpms TPM 1.2 backend will be the
>>>>>>> initial user of this functionality to store data that must persist
>>>>>>> through a reboot or migration.  A sample command line may look like
>>>>>>> this:
>>>>>>
>>>>>> This should be folded into the libtpms backend series.
>>>>>>
>>>>>> There are no users for this so this would just be untestable code in the
>>>>>> tree subject to bitrot.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Anthony Liguori
>>>>>>
>>>>>
>>>>> Fair enough.  I assume you're ok with this code though?
>>>>
>>>> I don't understand why it's needed to be honest.  I suspect this has to
>>>> do with the fact that the libtpms implementation will need significant
>>>> reworking.
>>>>
>>>> Regards,
>>>>
>>>> Anthony Liguori
>>>>
>>>
>>> In regards to why it is needed..  The QEMU software-emulated vTPM
>>> backend will pass callback functions to libtpms for writing/reading
>>> nvram data.  Those callbacks will use the code in this patch series to
>>> do the writing/reading of nvram data to/from image files so that the
>>> data persists through migration/reboot.
>>>
>>> I'm not sure I completely understand your second sentence, but yes the
>>> software-emulated vTPM backend code for QEMU will certainly need rework
>>> to use the code in this patch series.
>>
>> I think it's easiest to discuss this in the context of the actual patch
>> series.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>
> I suppose, but the earlier we can get feedback the better so that we 
> don't waste any more time.  This NVRAM code alone has gone through far 
> too many iterations as folks have asked for it to go in different 
> directions, and we went in those directions to find that they were the 
> wrong directions.

Yes, it's iterating because the context is missing.

> Anyway, for the record, this latest patch series 
> adheres to the direction you suggested we take last month: 
> http://lists.nongnu.org/archive/html/qemu-devel/2013-05/msg04275.html

No, my last suggestion was to just do bdrv_aio_write() within the device
itself.  I realize there is some complexity because libtpms is threaded
and this is exactly why the context matters so much.

But code isn't merged unless it's useful on its own.  This code is not
useful on its own.

Regards,

Anthony Liguori

>
> -- 
> Regards,
> Corey Bryant
>
>>>
>>> --
>>> Regards,
>>> Corey Bryant
>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Corey Bryant
>>>>>
>>>>>>>
>>>>>>> qemu-system-x86_64 ...
>>>>>>> -drive file=/path/to/nvram.qcow2,id=drive-nvram0-0-0
>>>>>>> -tpmdev libtpms,id=tpm-tpm0
>>>>>>> -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0,drive=drive-nvram0-0-0
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Corey
>>>>>>>
>>>>>>> Corey Bryant (3):
>>>>>>>      nvram: Add TPM NVRAM implementation
>>>>>>>      nvram: Add tpm-tis drive support
>>>>>>>      TPM NVRAM test
>>>>>>>
>>>>>>>     hw/tpm/Makefile.objs     |    1 +
>>>>>>>     hw/tpm/tpm_int.h         |    2 +
>>>>>>>     hw/tpm/tpm_nvram.c       |  324 ++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>     hw/tpm/tpm_nvram.h       |   25 ++++
>>>>>>>     hw/tpm/tpm_passthrough.c |   85 ++++++++++++
>>>>>>>     hw/tpm/tpm_tis.c         |    8 +
>>>>>>>     6 files changed, 445 insertions(+), 0 deletions(-)
>>>>>>>     create mode 100644 hw/tpm/tpm_nvram.c
>>>>>>>     create mode 100644 hw/tpm/tpm_nvram.h
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>