From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhgWL-0001sh-EG for qemu-devel@nongnu.org; Wed, 29 May 2013 09:34:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhgWG-0001Ku-Ie for qemu-devel@nongnu.org; Wed, 29 May 2013 09:34:29 -0400 Received: from e23smtp05.au.ibm.com ([202.81.31.147]:53055) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhgWG-0001KR-18 for qemu-devel@nongnu.org; Wed, 29 May 2013 09:34:24 -0400 Received: from /spool/local by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 29 May 2013 23:28:38 +1000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [9.190.235.21]) by d23dlp01.au.ibm.com (Postfix) with ESMTP id 4B5A12CE804D for ; Wed, 29 May 2013 23:34:14 +1000 (EST) Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4TDY5I125297142 for ; Wed, 29 May 2013 23:34:06 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4TDYCmB020554 for ; Wed, 29 May 2013 23:34:12 +1000 From: Anthony Liguori In-Reply-To: <519F86F3.80508@linux.vnet.ibm.com> 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> <519F86F3.80508@linux.vnet.ibm.com> Date: Wed, 29 May 2013 08:34:05 -0500 Message-ID: <87d2s96hbm.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 0/7] VNVRAM persistent storage List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Corey Bryant 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 Corey Bryant writes: > 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. Ack. > 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. Ack. > 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. Yes. > > Does this sound ok? Yup. Regards, Anthony Liguori > > -- > 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 >>>> >>>> >> >>