On Wed, 2013-01-16 at 17:48 +0000, David Vrabel wrote: > On 16/01/13 17:02, Ian Campbell wrote: > > On Wed, 2013-01-16 at 16:29 +0000, David Vrabel wrote: > >> Since the kexec hypercall is for use by dom0 I have removed the > >> implementation of the old load/unload ops and thus guests will require > >> updated kexec-tools to load images. Is this acceptable? > > > > How hard would it be to also support the old interface for the benefit > > of old kernels and userspaces (e.g. existing distros)? > > There's an easy way (see patch 1), but it doesn't have full > compatibility as it no longer executes the code page supplied by the > guest. This won't matter with Linux guests as their code pages can be > replaced by the code in Xen, but may matter with some more obscure > guests that do unusual things in their code pages (are there any like > this -- I doubt it?). I'm not sure that any other PV dom0 support kexec on Xen at all. > Full compatibility is possible and not that hard. Is it actually worth > it though? Will there be people updating Xen to 4.3 and unable to > update their kernel or userspace tools? We've been telling people for a while to try and use their distro packages where possible. Even if they build Xen from source it would be nice if they didn't have to also then rebuild their kernel or the kexec tools etc and could keep their existing packages. That said I'm not sure how widespread use of kexec is outside of distros anyway, and they can obviously integrate the right bits. > > Rather than a _v2 suffix we have in the past renamed the old ones > > _compat and introduced the new ones, with appropriate use of > > __XEN_INTERFACE_VERSION__ to paper over things for old users. > > > > See __HYPERVISOR_sched_op for example. > > Ok. I'll look at this. > > David
