[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/7] VNVRAM persistent storage

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?

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);


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]