qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] vNVRAM / blobstore design


From: Stefan Berger
Subject: Re: [Qemu-devel] vNVRAM / blobstore design
Date: Wed, 27 Mar 2013 13:27:39 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1

On 03/27/2013 01:14 PM, Anthony Liguori wrote:
Stefan Berger <address@hidden> 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.

I think the least one needs is to make the NVRAM/blobstore a bit more generic than making it too TPM-specific 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).

   Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]