On 05/23/2013 02:03 PM, Anthony Liguori wrote:
Corey Bryant <cor...@linux.vnet.ibm.com> writes:
This patch series provides VNVRAM persistent storage support that
QEMU can use internally. The initial target user will be a software
vTPM 1.2 backend that needs to store keys in VNVRAM and be able to
reboot/migrate and retain the keys.
This support uses QEMU's block driver to provide persistent storage
by reading/writing VNVRAM data from/to a drive image. The VNVRAM
drive image is provided with the -drive command line option just like
any other drive image and the vnvram_create() API will find it.
The APIs allow for VNVRAM entries to be registered, one at a time,
each with a maximum blob size. Entry blobs can then be read/written
from/to an entry on the drive. Here's an example of usage:
I still don't get why this needs to exist. This doesn't map to any
hardware concept I know of.
Why can't the vTPM manage on it's own how it stores blobs in it's flash
memory? I think we're adding an unneeded layer of abstraction here.
Regards,
Anthony Liguori
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.
--
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
