WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] struct shared_info extensibility (or lack thereof)


On 28 Nov 2005, at 18:01, Rik van Riel wrote:

It would allow us to grow the maximum supported number of
VCPUs in the future, without breaking backwards compatibility.

Any extension in the future can easily be made to backwards support old OSes, although they will be restricted to 32 VCPUs.

Of course, it would be useful to then put a few longs worth
of padding in front of the VCPU array, so we also have expansion
space in the non-per-VCPU part of shared_info.

Well, I'll leave vcpu_info where it is. We could maybe add some padding directly after it, but not sure it's worth it.

Two or three longs worth of padding per VCPU would be great, too. ;)

Six bytes plus another eight bytes are easily available (padding vcpu_info up to 64 bytes).

Having an interface that can be extended compatibly in the
future will make everybody's life so much easier.  Improving
Xen without breaking the already deployed virtual machines.

Sure, but extending MAX_VIRT_CPUS to 64 will require a big change one way or another. Either shared_info becomes multi-page, or we explicitly put extra vcpu_info's on a separate page. Probably we will do the latter if required.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel