From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ufu27-0002A3-Ln for qemu-devel@nongnu.org; Fri, 24 May 2013 11:36:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ufu20-0002aj-Vg for qemu-devel@nongnu.org; Fri, 24 May 2013 11:35:55 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:46960) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ufu20-0002ac-OV for qemu-devel@nongnu.org; Fri, 24 May 2013 11:35:48 -0400 Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 24 May 2013 09:35:48 -0600 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 54B7719D805C for ; Fri, 24 May 2013 09:27:53 -0600 (MDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4OFRoNs093140 for ; Fri, 24 May 2013 09:27:52 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4OFRnVb016822 for ; Fri, 24 May 2013 09:27:49 -0600 Message-ID: <519F86F3.80508@linux.vnet.ibm.com> Date: Fri, 24 May 2013 11:27:47 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1369331087-22345-1-git-send-email-coreyb@linux.vnet.ibm.com> <87txlt4lps.fsf@codemonkey.ws> <519E62DD.7060804@linux.vnet.ibm.com> <87ip29qzhb.fsf@codemonkey.ws> In-Reply-To: <87ip29qzhb.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 03:15 PM, Anthony Liguori wrote: > Corey Bryant writes: > >> On 05/23/2013 02:03 PM, Anthony Liguori wrote: >>> Corey Bryant 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.fsf@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. 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? -- 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 >>> >>> > >