Re: [Qemu-devel] vNVRAM / blobstore design

[Anthony Liguori <anthony@codemonkey.ws>]

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

>
> 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