Re: [Xen-devel] Domain Save Image Format proposal (draft B)

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 11/02/14 09:30, Ian Campbell wrote:
> On Mon, 2014-02-10 at 17:20 +0000, David Vrabel wrote:
>> 
>> Tools supporting version _V_ of the specification shall always save
>> images using version _V_.  Tools shall support restoring from version
>> _V_ and version _V_ - 1.
> 
> This isn't quite right since it is in terms of image format version and
> not Xen version (unless the two are to be linked somehow). The Xen
> project supports migration from version X-1 to version X (where X is the
> Xen version). It's not inconceivable that the image format version
> wouldn't change over Xen releases.

I was expecting it to be only necessary to bump the format version with
each Xen x.y release but I think you're right.  It may be needed to bump
the version of a x.y.z release.

>> --------------------------------------------------------------------
>> Field       Description
>> ----------- --------------------------------------------------------
>> marker      0xFFFFFFFFFFFFFFFF.
>>
>> id          0x58454E46 ("XENF" in ASCII).
>>
>> version     0x00000001.  The version of this specification.
>>
>> options     bit 0: Endianness.  0 = little-endian, 1 = big-endian.
> 
> Couldn't we just specify that things are in a specific endianness
> related to the header's arch field?
> 
> I appreciate the desire to make the format endian neutral and explicit
> about which is in use but (apart from the header) why would you ever
> want to go non-native endian for a given arch?

I am anticipating bi-endian architectures which could mean (for example)
migrating a little-endian guest from a little-endian host to a
big-endian host.

I would prefer to retain this bit, but I think we can specify that
certain architectures always use a specific endianness so initially we
wouldn't need to support anything other than the native endianness
(little-endian on both x86 and ARM).

>> --------------------------------------------------------------------
>> Field       Description
>> ----------- --------------------------------------------------------
>> arch        0x0000: Reserved.
>>
>>             0x0001: x86.
>>
>>             0x0002: ARM.
>>
>> type        0x0000: Reserved.
>>
>>             0x0001: x86 PV.
>>
>>             0x0002 - 0xFFFF: Reserved.
> 
> Is the type field per-arch? i.e. if arch=0x0002 can we use type = 0x0001
> for ARM domains?

I think it would be best to avoid reusing types for different
architectures -- it's not like we're going to be short on types.

>> P2M
>> ---
>>
>> [ This is a more flexible replacement for the old p2m_size field and
>> p2m array. ]
> 
> 
> What is the latter for again?

Er.  I think I've misunderstood the code and gotten confused here.

>> --------------------------------------------------------------------
>> 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.
> 
> Now might be a good time to remove this intertwining? I suppose 60-bits
> is a lot of pfn's, but if the VMs address space is sparse it isn't out
> of the question.

I don't think we want to consider systems with > 64 bits of address
space so 60-bits is more than enough for PFNs.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel