This changeset: changeset: 8551:c6f7774cae63932f327413586d58f3c7d08cb378 description: 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 ones)? 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 anyway? It seems that at least these structures need some padding to allow further additions without breaking the ABI. Comments? thanks, john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 30 Jul 2006, at 13:00, John Levon wrote:> 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 > ones)?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. 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. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
On 30 Jul 2006, at 20:50, John Levon wrote:> 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.A fixed pseudophysical address known to your OS and your debugger? Then you just read it out of guest RAM -- no need for changes to core-dump routines. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Jul 31, 2006 at 10:06:04AM +0100, Keir Fraser wrote:> >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. > > A fixed pseudophysical address known to your OS and your debugger?Encoding a special gpfn into our ABI seems very inflexible, and would mean it''s no longer as simple as a kmalloc(). I''d be extremely concerned about future changes making the known gpfn a problem years down the line... We could do a fixed virtual address that we know about and walk from the vcpu''s ctrlregs[3] at least (it looks like this always the kernel cr3 or good enough), but it still seems better to not have another fixed address the debugger has to know about.> no need for changes to core-dump routines.We''d also like to see further changes to Xen domain core dumps anyway to help self-identify /what/ it is: thinks like the word size, version[1], and especially the shared info contents[2], which is often extremely useful for debugging. Ideally this would also apply to save files, so we could plug in a backend to our debugger and magically get debugging of live domains, cores, and save files. regards john [1] as it is now, the core file format isn''t versioned, unless you go the route of changing the magic each time [2] I could be wrong but I don''t believe the shared info frame is dumped into the core _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel