[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |