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

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

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.  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.

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.

Does this sound ok?

-- 
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
>>>
>>>
>
>