Corey Bryant <cor...@linux.vnet.ibm.com> writes: > 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.
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 >>>> >>>> >> >>