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 Mon, 28 Nov 2005, Keir Fraser wrote:
> On 28 Nov 2005, at 16:47, Rik van Riel wrote:
> 
> > The reason for putting the vcpu_* structures together on a per
> > virtual cpu basis is that this way we can extend the number of
> > virtual CPUs in the future, without breaking the interface with
> > older guests.
> 
> Actually, thinking about it, putting all vcpu info in a 64-byte block 
> makes sense for cache locality....
> 
> I don't think that relocating the vcpu info at the end of the page buys 
> us anything significant though.

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

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.

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

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.

-- 
All Rights Reversed

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