From: Corey Bryant <coreyb@linux.vnet.ibm.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: kwolf@redhat.com, stefanb@linux.vnet.ibm.com,
mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org,
jschopp@linux.vnet.ibm.com, stefanha@redhat.com,
lcapitulino@redhat.com
Subject: Re: [Qemu-devel] [PATCH 0/7] VNVRAM persistent storage
Date: Thu, 23 May 2013 14:41:33 -0400 [thread overview]
Message-ID: <519E62DD.7060804@linux.vnet.ibm.com> (raw)
In-Reply-To: <87txlt4lps.fsf@codemonkey.ws>
On 05/23/2013 02:03 PM, Anthony Liguori wrote:
> Corey Bryant <coreyb@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
>
>
next prev parent reply other threads:[~2013-05-23 18:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-23 17:44 [Qemu-devel] [PATCH 0/7] VNVRAM persistent storage Corey Bryant
2013-05-23 17:44 ` [Qemu-devel] [PATCH 1/7] vnvram: VNVRAM bdrv support Corey Bryant
2013-05-24 13:06 ` Kevin Wolf
2013-05-24 15:33 ` Corey Bryant
2013-05-24 15:37 ` Kevin Wolf
2013-05-24 15:47 ` Corey Bryant
2013-05-23 17:44 ` [Qemu-devel] [PATCH 2/7] vnvram: VNVRAM in-memory support Corey Bryant
2013-05-23 17:44 ` [Qemu-devel] [PATCH 3/7] vnvram: VNVRAM bottom-half r/w scheduling support Corey Bryant
2013-05-23 17:44 ` [Qemu-devel] [PATCH 4/7] vnvram: VNVRAM internal APIs Corey Bryant
2013-05-23 17:44 ` [Qemu-devel] [PATCH 5/7] vnvram: VNVRAM additional debug support Corey Bryant
2013-05-23 17:44 ` [Qemu-devel] [PATCH 6/7] main: Initialize VNVRAM Corey Bryant
2013-05-23 17:44 ` [Qemu-devel] [PATCH 7/7] monitor: QMP/HMP support for retrieving VNVRAM details Corey Bryant
2013-05-23 17:59 ` Eric Blake
2013-05-23 18:43 ` Corey Bryant
2013-05-29 17:15 ` Luiz Capitulino
2013-05-29 17:34 ` Corey Bryant
2013-05-23 18:03 ` [Qemu-devel] [PATCH 0/7] VNVRAM persistent storage Anthony Liguori
2013-05-23 18:41 ` Corey Bryant [this message]
2013-05-23 19:15 ` Anthony Liguori
2013-05-24 15:27 ` Corey Bryant
2013-05-29 13:34 ` Anthony Liguori
2013-05-24 9:59 ` Stefan Hajnoczi
2013-05-24 12:13 ` Stefan Berger
2013-05-24 12:36 ` Stefan Hajnoczi
2013-05-24 15:39 ` Corey Bryant
2013-05-27 8:40 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=519E62DD.7060804@linux.vnet.ibm.com \
--to=coreyb@linux.vnet.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=jschopp@linux.vnet.ibm.com \
--cc=kwolf@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanb@linux.vnet.ibm.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).