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/
Home Products Support Community News


Re: [Xen-devel] Stability of shared info structs?

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Stability of shared info structs?
From: John Levon <levon@xxxxxxxxxxxxxxxxx>
Date: Sun, 30 Jul 2006 20:50:22 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 30 Jul 2006 12:50:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <061d002a2a5d2cd3da9b9d46fa05985d@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060730120053.GA3352@xxxxxxxxxxxxxxxxxxxx> <061d002a2a5d2cd3da9b9d46fa05985d@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
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.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>