All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.vnet.ibm.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	Kent E Yoder <yoder1@us.ibm.com>,
	Corey Bryant <coreyb@linux.vnet.ibm.com>,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Joel Schopp <jschopp@linux.vnet.ibm.com>,
	Kenneth Goldman <kgoldman@us.ibm.com>
Subject: Re: [Qemu-devel] vNVRAM / blobstore design
Date: Wed, 27 Mar 2013 13:27:39 -0400	[thread overview]
Message-ID: <51532C0B.1050108@linux.vnet.ibm.com> (raw)
In-Reply-To: <87k3os7okn.fsf@codemonkey.ws>

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

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	other threads:[~2013-03-27 17:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-25 21:39 [Qemu-devel] vNVRAM / blobstore design Stefan Berger
2013-03-25 22:05 ` Anthony Liguori
2013-03-25 22:20   ` Stefan Berger
2013-03-27 15:17     ` Corey Bryant
2013-03-27 15:20       ` Corey Bryant
2013-03-27 15:30         ` Michael S. Tsirkin
2013-03-27 16:07           ` mdroth
2013-03-27 15:43         ` Kenneth Goldman
2013-03-27 15:53           ` Michael S. Tsirkin
2013-03-27 16:12             ` Joel Schopp
2013-03-27 16:46               ` Stefan Berger
2013-03-27 17:14                 ` Anthony Liguori
2013-03-27 17:27                   ` Stefan Berger [this message]
2013-03-27 18:27                     ` Anthony Liguori
2013-03-27 19:12                       ` Stefan Berger
2013-03-28 16:11                         ` Stefan Berger
2013-03-28 16:31                           ` Michael S. Tsirkin
2013-03-28 17:02                             ` Stefan Berger
2013-03-28 17:27                           ` Anthony Liguori
2013-03-28 17:36                             ` Stefan Berger
2013-03-28 17:39                             ` Michael S. Tsirkin
2013-03-29 13:55                               ` Stefan Berger
2013-03-29 15:12                                 ` Anthony Liguori
2013-03-29 17:33                           ` Kenneth Goldman
2013-03-31  8:17                             ` Michael S. Tsirkin
2013-03-31 20:48                               ` Kenneth Goldman
2013-04-02 12:06                                 ` Michael S. Tsirkin
2013-04-02 13:24                                   ` Kenneth Goldman
2013-04-02 13:37                                     ` Michael S. Tsirkin
2013-03-27 18:04                   ` Michael S. Tsirkin
2013-03-27 16:20             ` Kenneth Goldman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51532C0B.1050108@linux.vnet.ibm.com \
    --to=stefanb@linux.vnet.ibm.com \
    --cc=anthony@codemonkey.ws \
    --cc=coreyb@linux.vnet.ibm.com \
    --cc=jschopp@linux.vnet.ibm.com \
    --cc=kgoldman@us.ibm.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=yoder1@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.