[Top][All Lists]

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

Re: [Qemu-devel] blobstore disk format (was Re: Design of the blobstore)

From: Stefan Berger
Subject: Re: [Qemu-devel] blobstore disk format (was Re: Design of the blobstore)
Date: Wed, 21 Sep 2011 21:44:37 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11

On 09/19/2011 03:04 PM, Michael S. Tsirkin wrote:
On Mon, Sep 19, 2011 at 12:22:02PM -0400, Stefan Berger wrote:
On 09/17/2011 03:28 PM, Michael S. Tsirkin wrote:
On Fri, Sep 16, 2011 at 12:46:40PM -0400, Stefan Berger wrote:

The checksuming I think makes sense if encryption is being added so
decryption and testing for proper key material remains an NVRAM
operation rather than a device operation.
Not sure how this addresses the question of what to do
on checksum failure.

Checksum failure on an unencrypted blob would mean that the blob is corrupted. In case of encryption 'corrupted' would overlap with a 'badly decrypted' blob. In either way the startup of the device cannot happen. We could refuse the NVRAM key suggesting that likely this is the wrong key for decryption but corruption is also possible.
We use a directory as a SET in a CER format.
This allows generating directory online without scanning
the entries beforehand.

I guess it is the 'unknown' for me... but what is the advantage of
using ASN1 for this rather than just writing out packed and
endianess-normalized data structures (with revision value),
If you want an example of where this 'custom formats are easy
so let us write one' leads to in the end,
look no further than live migration code.
It's a mess of hacks that does not even work across
upstream qemu versions, leave alone across
downstreams (different linux distros).

So is ASN1 the answer or does one still need to add a revision tag
to each blob putting in custom code for parsing the different
revisions of data structures (I guess) that may be extended/changed
over time?

We don't need revisions. We can always parse a new structure
skipping optional attributes we don't recognize. In case we want to
break old qemu versions intentially, we can add
a mandatory attribute.
So you said you had some code for the handling of ASN.1. Can sketch
how the interaction of devices would work with mandatory and
optional attributes along with an API?
So for now what I'm happy with is a low level BER parser API.
NVRAM would implement a scheme on top of that
and bdrv. I'll pack up what I have and post ASAP.

I had thought that registration of a blob could include the registration of something similar to the VMStateDescription's fields array (VMStateField[]) that currently is not encoded as ASN.1 but seems to be heading that way. I am not sure what the time frame for this is but I guess recycling as much code as possible would be helpful. For the purpose of NVRAM we would have to be able to determine the size of these additional metadata, something that is not necessary for the case of VM migration/suspend. I guess using VIsitors it should be possible to implement this type of functionality. Also extending the metadata in the future with new fields will be a lot harder with NVRAM due to the limited space we will have reserved when the blob + metadata was written out the first time.

I'd prefer to NOT have the
attributes and values be a part of the NVRAM API itself but let a
(mandatory) library handle the serialization and deserialization of
these metadata when a device wants to write or read state
respectively. But maybe I just want to keep the NVRAM API 'too

I'm fine with that. Still tpm has some device specific
things like 'actual size' so the api will need to address that
in some generic way.
Maybe the above mentioned registration of the VMStateField[] could help.


reply via email to

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