On 05/23/2013 03:15 PM, Anthony Liguori wrote:
Corey Bryant <cor...@linux.vnet.ibm.com> writes:
On 05/23/2013 02:03 PM, Anthony Liguori wrote:
Corey Bryant <cor...@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....@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