[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/7] VNVRAM persistent storage
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [PATCH 0/7] VNVRAM persistent storage |
Date: |
Wed, 29 May 2013 08:34:05 -0500 |
User-agent: |
Notmuch/0.15.2+77~g661dcf8 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) |
Corey Bryant <address@hidden> writes:
> On 05/23/2013 03:15 PM, Anthony Liguori wrote:
>> Corey Bryant <address@hidden> writes:
>>
>>> On 05/23/2013 02:03 PM, Anthony Liguori wrote:
>>>> Corey Bryant <address@hidden> 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/address@hidden
>>
>
> 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
>>>>
>>>>
>>
>>
- Re: [Qemu-devel] [PATCH 7/7] monitor: QMP/HMP support for retrieving VNVRAM details, (continued)
Re: [Qemu-devel] [PATCH 0/7] VNVRAM persistent storage, Anthony Liguori, 2013/05/23
Re: [Qemu-devel] [PATCH 0/7] VNVRAM persistent storage, Stefan Hajnoczi, 2013/05/24