Stefan Berger <stef...@linux.vnet.ibm.com> writes: > On 03/27/2013 01:14 PM, Anthony Liguori wrote: >> Stefan Berger <stef...@linux.vnet.ibm.com> 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. The long version is below. > I think the least one needs is to make the NVRAM/blobstore a bit more > generic than making it too TPM-specific 'blobstore' is not a hardware concept so making it generic is solving a problem that doesn't exist. Hardware typically falls into one of a few categories: 1) No persistent state 2) Persistent state stored in flash/eeprom in a way that's completely opaque to software 3) Persistent state stored in flash/eeprom that's visible (either directly or indirectly) to software. For (1), there's no discussion here. For (3), we're forced to use the same layout that real hardware uses to make the software interface the same. As it turns out (2) is almost always such a small amount of state that it basically doesn't matter. It's usually stuff like hardware mac addresses so we don't even bother storing in a marshalled format. We just accept properties during device creation. (2) is rare for large amounts of state because it'd be a waste of hardware to design an interface on top of NVRAM that is only going to serve as an API for the device driver which is usually produced by the same company anyway. So this is really just not a problem even worth trying to solve. Even if it was.... > is to provide a layer that > organizes the blobs the device may produce and provides functions to > register those blobs, have them read or written to without the device > knowing where exactly the data are located on the storage device. A > nugget of the 1st implementation was that we could encrypt the blobs > themselves easily which made it also easier to support encrypted blobs > on non-QCOW2 devices (modulo the loss of snapshotting then). There is already an API for store named "blobs" that allow them to be individually encrypted or handled in QEMU. It's called the Linux VFS interface. Really, this whole blobstore thing is just a half-hearted filesystem. This is why the design rat-holed so quickly. If we need to use a filesystem, just use the host filesystem and call it a day. Regards, Anthony Liguori > > Stefan
