From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: Domain Save Image Format proposal (draft B) Date: Tue, 11 Feb 2014 11:58:33 +0000 Message-ID: <52FA1069.2040709@citrix.com> References: <52F90A71.40802@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: rshriram@cs.ubc.ca Cc: Stefano Stabellini , Ian Jackson , Ian Campbell , "Xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 10/02/14 20:00, Shriram Rajagopalan wrote: > On Mon, Feb 10, 2014 at 9:20 AM, David Vrabel > wrote: > > > Its tempting to adopt all the TCP-style madness for transferring a set of > structured data. Why this endian-ness mess? Am I missing something here? > I am assuming that a lion's share of Xen's deployment is on x86 > (not including Amazon). So that leaves ARM. Why not let these > processors take the hit of endian-ness conversion? I'm not sure I would characterize a spec being precise about byte ordering as "endianness mess". I think it would be a pretty poor specification if it didn't specify byte ordering -- we can't have the tools having to make assumptions about the ordering. However, I do think it can be specified in such a way that all the current use cases don't have to do any byte swapping (except for the minimal header). > +-----------------------+-------------------------+ > | checksum | (reserved) | > +-----------------------+-------------------------+ > > > I am assuming that you the checksum field is present only > for debugging purposes? Otherwise, I see no reason for the > computational overhead, given that we are already sending data > over a reliable channel + IIRC we already have an image-wide checksum > when saving the image to disk. I'm not aware of any image wide checksum. The checksum seems like a potentially useful feature but I don't have a requirement for it so if no one else thinks it is useful it can be removed. > PAGE_DATA > --------- [...] > -------------------------------------------------------------------- > Field Description > ----------- -------------------------------------------------------- > count Number of pages described in this record. > > pfn An array of count PFNs. Bits 63-60 contain > the XEN\_DOMCTL\_PFINFO_* value for that PFN. > > page_data page_size octets of uncompressed page contents for each page > set as present in the pfn array. > -------------------------------------------------------------------- > > > s/uncompressed/(compressed/uncompressed)/ > (Remus sends compressed data) No. I think compressed page data should have its own record type. The current scheme of mode flipping records seems crazy to me. > x86 PV Guest > ------------ > > An x86 PV guest image will have in this order: > > 1. Image header > 2. Domain header > 3. X86_PV_INFO record > 4. At least one P2M record > 5. At least one PAGE_DATA record > > 6. VCPU_INFO record > 6. At least one VCPU_CONTEXT record > > 7. END record > > > There seems to be a bunch of info missing. Here are some > missing elements that I can recall at the moment: > a) there is no support for sending over one time markers that switch the > receiver's operating mode in the middle of a data stream. > E.g., XC_SAVE_ENABLE_COMPRESSION, XC_SAVE_ID_LAST_CHECKPOINT, etc. > XC_SAVE_ENABLE_VERIFY_MODE, Yes. As I noted, this specification is not yet complete. David