On 11.06.20 17:27, Julien Grall wrote:
Hi,
On 11/06/2020 16:21, Jürgen Groß wrote:
On 11.06.20 16:57, Julien Grall wrote:
Hi all,
kexec-tools has an option to load dynamically libxenctlr.so (not
.so.4.x) (see [1]).
Given that the library has never been considered stable, it is
probably a disaster that is waiting to happen.
Looking at the tree kexec is using the follow libxc functions:
- xc_kexec_get_range()
- xc_kexec_load()
- xc_kexec_unload()
- xc_kexec_status()
- xc_kexec_exec()
- xc_version()
- xc_interface_open()
- xc_interface_close()
- xc_get_max_cpus()
- xc_get_machine_memory_map()
I think it is uncontroversial that we want a new stable library for
all the xc_kexec_* functions (maybe libxenexec)?
However I am not entirely sure where to put the others.
I am thinking to introduce libxensysctl for xc_get_max_cpus() as it
is a XEN_SYSCTL. We could possibly include
xc_get_machine_memory_map() (despite it is a XENMEM_).
For xc_version(), I am thinking to extend libxentoolcore to also
include "stable xen API".
Any opinion on the approach?
You could consider hypfs (at least for some of the functionality).
That would work!
xc_version() and xc_get_max_cpus() would be rather easy.
I am guessing we will need a fallback to the normal hypercalls if hypfs
is not present.
Or we don't support kexec-tools running on a system without hypfs
(or the related functions would return an error on those systems).
xc_get_machine_memory_map() is using a stable hypercall used by
the kernel, too.
IIUC, you are suggesting to put this one in hypfs library as well. Is
that correct?
Not really. I wanted to point out that this call would be a good
candidate for another stable library, maybe part of libxenexec?
In theory the memory map could be dumped via a hypfs node, either
as a string (not nice for working with it) or as binary blob, of
course.
Juergen
