From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfaUA-00020A-Sm for qemu-devel@nongnu.org; Thu, 23 May 2013 14:43:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfaU9-0002y2-DR for qemu-devel@nongnu.org; Thu, 23 May 2013 14:43:34 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:60548) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfaSV-0002Pq-En for qemu-devel@nongnu.org; Thu, 23 May 2013 14:41:51 -0400 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 23 May 2013 12:41:50 -0600 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 1960A38C8042 for ; Thu, 23 May 2013 14:41:47 -0400 (EDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4NIfkh0304514 for ; Thu, 23 May 2013 14:41:47 -0400 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4NIfchV031170 for ; Thu, 23 May 2013 12:41:38 -0600 Message-ID: <519E62DD.7060804@linux.vnet.ibm.com> Date: Thu, 23 May 2013 14:41:33 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1369331087-22345-1-git-send-email-coreyb@linux.vnet.ibm.com> <87txlt4lps.fsf@codemonkey.ws> In-Reply-To: <87txlt4lps.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/7] VNVRAM persistent storage List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori 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 On 05/23/2013 02:03 PM, Anthony Liguori wrote: > Corey Bryant 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 > >