From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULFis-0005ly-Dj for qemu-devel@nongnu.org; Thu, 28 Mar 2013 12:30:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ULFip-0006wd-Gh for qemu-devel@nongnu.org; Thu, 28 Mar 2013 12:30:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7330) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULFip-0006wY-8T for qemu-devel@nongnu.org; Thu, 28 Mar 2013 12:30:39 -0400 Date: Thu, 28 Mar 2013 18:31:08 +0200 From: "Michael S. Tsirkin" Message-ID: <20130328163108.GA30183@redhat.com> References: <51530E4B.2010203@linux.vnet.ibm.com> <20130327155303.GB29523@redhat.com> <51531A51.3050709@linux.vnet.ibm.com> <51532268.40102@linux.vnet.ibm.com> <87k3os7okn.fsf@codemonkey.ws> <51532C0B.1050108@linux.vnet.ibm.com> <87ehf03dgw.fsf@codemonkey.ws> <515344AB.2030403@linux.vnet.ibm.com> <51546BAA.60504@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51546BAA.60504@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] vNVRAM / blobstore design List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger Cc: Stefan Hajnoczi , Kent E Yoder , Corey Bryant , Michael Roth , qemu-devel , Joel Schopp , Kenneth Goldman , Anthony Liguori On Thu, Mar 28, 2013 at 12:11:22PM -0400, Stefan Berger wrote: > On 03/27/2013 03:12 PM, Stefan Berger wrote: > >On 03/27/2013 02:27 PM, Anthony Liguori wrote: > >>Stefan Berger writes: > >> > >>>On 03/27/2013 01:14 PM, Anthony Liguori wrote: > >>>>Stefan Berger writes: > >>>> > >>>>What I struggle with is that we're calling this a "blobstore". Using > >>>>BER to store "blobs" seems kind of pointless especially when we're > >>>>talking about exactly three blobs. > >>>> > >>>>I suspect real hardware does something like, flash is N > >>>>bytes, blob 1 is > >>>>a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is > >>>>(N - X - Y) > >>>>bytes. > >>>> > >>>>Do we really need to do anything more than that? > >>>I typically call it NVRAM, but earlier discussions seemed to prefer > >>>'blobstore'. > >>> > >>>Using BER is the 2nd design of the NVRAM/blobstore. The 1st one didn't > >>>use any visitors but used a directory in the first sector pointing to > >>>the actual blobs in other sectors of the block device. The organization > >>>of the directory and assignment of the blobs to their sectors, aka 'the > >>>layout of the data' in the disk image, was handled by the > >>>NVRAM/blobstore implementation. > >>Okay, the short response is: > >> > >>Just make the TPM have a DRIVE property, drop all notion of > >>NVRAM/blobstore, and used fixed offsets into the BlockDriverState for > >>each blob. > > > >Fine by me. I don't see the need for visitors. I guess sharing of > >the persistent storage between different types of devices is not a > >goal here so that a layer that hides the layout and the blobs' > >position within the storage would be necessary. Also fine by me > >for as long as we don't come back to this discussion. > > One thing I'd like to get clarity about is the following > corner-case. A user supplies some VM image as persistent storage for > the TPM. It contains garbage. How do we handle this case? Does the > TPM then just start writing its state into this image or do we want > to have some layer in place that forces a user to go through the > step of formatting after that layer indicates that the data are > unreadable. Besides that a completely empty image also contains > garbage from the perspective of TPM persistent state and for that > layer. > > My intention would (again) be to put a header in front of every > blob. That header would contain a crc32 covering that header (minus > the crc32 field itself of course) plus the blob to determine whether > the blob is garbage or not. It is similar in those terms as the 1st > implementation where we also had a directory that contained that > crc32 for the directory itself and for each blob. This is not a > filesystem, I know that. > > Regards, > Stefan > > It was precisely this addition of more and more metadata that made me suggest a format like BER. But of course a file per field will do too: following what Anthony suggested you would put the checksum in a separate file? -- MST