[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.