From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKtvS-0001hr-3z for qemu-devel@nongnu.org; Wed, 27 Mar 2013 13:14:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKtvM-0003Us-DC for qemu-devel@nongnu.org; Wed, 27 Mar 2013 13:14:14 -0400 Received: from mail-qe0-f41.google.com ([209.85.128.41]:57903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKtvM-0003Uj-9G for qemu-devel@nongnu.org; Wed, 27 Mar 2013 13:14:08 -0400 Received: by mail-qe0-f41.google.com with SMTP id 7so4722839qeb.14 for ; Wed, 27 Mar 2013 10:14:07 -0700 (PDT) From: Anthony Liguori In-Reply-To: <51532268.40102@linux.vnet.ibm.com> References: <5150C415.9030302@linux.vnet.ibm.com> <87ehf3nnja.fsf@codemonkey.ws> <5150CDA8.3020300@linux.vnet.ibm.com> <51530DA2.2030409@linux.vnet.ibm.com> <51530E4B.2010203@linux.vnet.ibm.com> <20130327155303.GB29523@redhat.com> <51531A51.3050709@linux.vnet.ibm.com> <51532268.40102@linux.vnet.ibm.com> Date: Wed, 27 Mar 2013 12:14:00 -0500 Message-ID: <87k3os7okn.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] vNVRAM / blobstore design List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger , Joel Schopp Cc: "Michael S. Tsirkin" , Stefan Hajnoczi , Kent E Yoder , Corey Bryant , Michael Roth , qemu-devel , Kenneth Goldman Stefan Berger 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