Re: [Qemu-devel] [PATCH 0/7] VNVRAM persistent storage

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

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

> On 05/23/2013 03:15 PM, Anthony Liguori wrote:
>> Corey Bryant <coreyb@linux.vnet.ibm.com> writes:
>>
>>> On 05/23/2013 02:03 PM, Anthony Liguori wrote:
>>>> Corey Bryant <coreyb@linux.vnet.ibm.com> writes:
>>>>
>>> One of the difficulties in virtualizing a TPM is that it doesn't support
>>> SR-IOV.  So the existing passthrough vTPM can only be used by one guest.
>>>    We're planning to provide a software emulated vTPM that uses libtpms
>>> and it needs to store blobs somewhere that is persistent.  We can't
>>> store blobs in the host TPM's hardware NVRAM.  So we have to virtualize
>>> it in software.  And we figured we'd provide a persistent storage
>>> mechanism that other parts of QEMU could use rather than limit it to
>>> just the vTPM's use.
>>
>> I think you are misunderstanding my feedback.
>>
>> See http://mid.gmane.org/87ehf03dgw.fsf@codemonkey.ws
>>
>
> It looks like we'll be able to follow what you said in that thread, 
> specifically:
>
> "Just make the TPM have a DRIVE property, drop all notion of
> NVRAM/blobstore, and used fixed offsets into the BlockDriverState for
> each blob."
>
> This will limit the functionality to only the vTPM, but it sounds like 
> that's desired.

Ack.

> Also it looks like vTPM 1.2 will only have 4 blobs and 
> we'll know their max sizes, so we should be able to use fixed offsets 
> for them.  This will simplify the code quite a bit.

Ack.

> I assume we'll still need to use a bottom-half to send read/write 
> requests to the main thread.  And from the sounds of it the reads/writes 
> will need to be asynchronous.

Yes.

>
> Does this sound ok?

Yup.

Regards,

Anthony Liguori

>
> -- 
> Regards,
> Corey Bryant
>
>
>
>>>>>
>>>>> VNVRAM *vnvram;
>>>>> int errcode
>>>>> const VNVRAMEntryName entry_name;
>>>>> const char *blob_w = "blob data";
>>>>> char *blob_r;
>>>>> uint32_t blob_r_size;
>>>>>
>>>>> vnvram = vnvram_create("drive-ide0-0-0", false, &errcode);
>>>>> strcpy((char *)entry_name, "first-entry");
>>>>> vnvram_register_entry(vnvram, &entry_name, 1024);
>>>>> vnvram_write_entry(vnvram, &entry_name, (char *)blob_w, strlen(blob_w)+1);
>>>>> vnvram_read_entry(vnvram, &entry_name, &blob_r, &blob_r_size);
>>>>> vnvram_delete(vnvram);
>>>>>
>>>>> Thanks,
>>>>> Corey
>>>>>
>>>>> Corey Bryant (7):
>>>>>     vnvram: VNVRAM bdrv support
>>>>>     vnvram: VNVRAM in-memory support
>>>>>     vnvram: VNVRAM bottom-half r/w scheduling support
>>>>>     vnvram: VNVRAM internal APIs
>>>>>     vnvram: VNVRAM additional debug support
>>>>>     main: Initialize VNVRAM
>>>>>     monitor: QMP/HMP support for retrieving VNVRAM details
>>>>>
>>>>>    Makefile.objs    |    2 +
>>>>>    hmp.c            |   32 ++
>>>>>    hmp.h            |    1 +
>>>>>    monitor.c        |    7 +
>>>>>    qapi-schema.json |   47 ++
>>>>>    qmp-commands.hx  |   41 ++
>>>>>    vl.c             |    6 +
>>>>>    vnvram.c         | 1254 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>    vnvram.h         |   36 ++
>>>>>    9 files changed, 1426 insertions(+), 0 deletions(-)
>>>>>    create mode 100644 vnvram.c
>>>>>    create mode 100644 vnvram.h
>>>>
>>>>
>>
>>