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


[Xen-devel] Stability of shared info structs?

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Stability of shared info structs?
From: John Levon <levon@xxxxxxxxxxxxxxxxx>
Date: Sun, 30 Jul 2006 13:00:53 +0100
Delivery-date: Sun, 30 Jul 2006 05:01:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
This changeset:

changeset:   8551:c6f7774cae63932f327413586d58f3c7d08cb378
Pass NMIs to DOM0 via a dedicated callback, core Xen support.

appears to have modified the size of struct arch_shared_info, as far as
I know, after the interface was supposed to be stable. This would have
broken any 3.0 domUs using the size of the shared_info structure for
whatever reason. Was this an error, or is the implication that a domU
cannot take the size of certain shared structures (and if so, which

We have a need to introduce a new field to shared info:

xen_pfn_t dom_info_pfn;

This would be a domain-set PFN allowing self-contained introspection.
Currently, any introspection (e.g. via gdb) requires information outside
of the domain such as the correct kernel binary. With this pfn, tools
would be able to look into some domain-provided structure to allow
introspection to "bootstrap" itself. Of course for cores and save files
this would require modifications to store the shared info page, but this
is both a good thing, and I understand there are format changes planned

It seems that at least these structures need some padding to allow
further additions without breaking the ABI.



Xen-devel mailing list

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