Re: [Qemu-devel] vNVRAM / blobstore design

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Mar 27, 2013 at 12:14:00PM -0500, Anthony Liguori wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> 
> > On 03/27/2013 12:12 PM, Joel Schopp wrote:
> >>
> >>> Yea it's not hard to invent a random format each time we write something
> >>> on disk.
> >>>
> >>> But I think ASN.1 BER will be useful to have in qemu anyway. E.g. it's a
> >>> better format for migration than what we have now.  Once we have it in
> >>> tree re-using it seems cleaner than maintaining some per-TPM thing.
> >>>
> >>
> >> The asn.1 patches that have been posted seem to be getting a cool 
> >> reception.  If people think asn.1 is the way to go some more review 
> >> comments, acked-bys, reviewed-bys, or signed-off-bys would make that 
> >> more likely to happen.  The patches have gone through several rounds 
> >> of review and come with a decent set of tests but still haven't been 
> >> merged.  I think they are very mergable.
> >
> > Let me post another version that makes all the tests in 
> > test-visitor-serialize pass, including the ones using visit_optional.
> 
> 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?
> 
> Regards,
> 
> Anthony Liguori

Last I looked some metadata was stored per blob, for example
I think it has a concept of "number of bytes initialized".
So we'll need to serialize that.
More can come with time ...

> 
> >
> > I also think they are mergeable, but we should discuss a few aspects 
> > around it. There are standards behind this that we may or may not need 
> > to implement as such. I am thinking of CER encoding for example that 
> > imposes restrictions on the size of primitive elements to be less than 
> > 1000 bytes (section 9.2) and need constructed encoding when bigger. We 
> > may be able to change this limit to PAGE_SIZE * n with n = ?. There may 
> > be other aspects.
> >
> > Stefan