[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] vNVRAM / blobstore design
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] vNVRAM / blobstore design |
Date: |
Wed, 27 Mar 2013 20:04:34 +0200 |
On Wed, Mar 27, 2013 at 12:14:00PM -0500, Anthony Liguori wrote:
> Stefan Berger <address@hidden> 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
- Re: [Qemu-devel] vNVRAM / blobstore design, (continued)
- Re: [Qemu-devel] vNVRAM / blobstore design, Anthony Liguori, 2013/03/28
- Re: [Qemu-devel] vNVRAM / blobstore design, Stefan Berger, 2013/03/28
- Re: [Qemu-devel] vNVRAM / blobstore design, Michael S. Tsirkin, 2013/03/28
- Re: [Qemu-devel] vNVRAM / blobstore design, Stefan Berger, 2013/03/29
- Re: [Qemu-devel] vNVRAM / blobstore design, Anthony Liguori, 2013/03/29
- Re: [Qemu-devel] vNVRAM / blobstore design, Kenneth Goldman, 2013/03/29
- Re: [Qemu-devel] vNVRAM / blobstore design, Michael S. Tsirkin, 2013/03/31
- Re: [Qemu-devel] vNVRAM / blobstore design, Kenneth Goldman, 2013/03/31
- Re: [Qemu-devel] vNVRAM / blobstore design,
Michael S. Tsirkin <=
- Re: [Qemu-devel] vNVRAM / blobstore design, Kenneth Goldman, 2013/03/27