On Sun, Jul 30, 2006 at 06:07:34PM +0100, Keir Fraser wrote:
> Since shared_info is always in a Xen-provided page, we think it's okay
> to add extra entries to the end of it. I don't think we could get away
> with that with any of the other public structures.
OK, then the header files need to clearly document this lack of ABI.
There are, however, two further problems:
1) new fields can only ever go in arch_shared_info, since it may change
at will. No field can go either before or after the "arch" member of
struct shared_info, as either can or will change known offsets.
2) there needs to be some written guarantee that the region < PAGE_SIZE,
> sizeof(xen 3.0's shared_info), can always be writable by a guest,
otherwise a newer guest can only safely use new fields based upon
hypervisor version checks, which is pretty horrible.
The first problem seems particularly troublesome, which is why I'd
prefer explicit padding in at least the arch_shared_info now, so all new
fields have a guaranteed offset.
> We might add an extra field for introspection -- it depends precisely
> what it's for. There are one or two fields used for communicating
> between guest and tools, but that isn't what shared_info was originally
> intended for. It might, for example, be better to use xenstore.
Xenstore is only useful on the machine at the time, not more general
post-mortem debugging. There needs to be something to allow
introspection of domain core dumps in a self-contained manner. If you
have a better suggestion for where this might go, then great.
regards
john
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home