|
From: | Corey Bryant |
Subject: | Re: [Qemu-devel] [PATCH 0/7] VNVRAM persistent storage |
Date: | Fri, 24 May 2013 11:27:47 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 |
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. 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
[Prev in Thread] | Current Thread | [Next in Thread] |