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.
5 messages in com.xensource.lists.xen-develRe: [Xen-devel] struct shared_info ex...