Re: Kexec and libxenctlr.so

[Wei Liu <wl@xxxxxxx>]

On Thu, Jun 11, 2020 at 03:57:37PM +0100, 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)?

That sounds fine to me.

Looking at the list of functions, all the xc_kexec_* ones are probably
already rather stable.

For xc_interface_open / close, they are perhaps used only to obtain an
xc handle such that it can be used to make hypercalls. You new kexec
library is going to expose its own handle with a xencall handle wrapped
inside, so you can do away with an xc handle.

> 
> 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_).
> 

Introducing an libxensysctl before we stabilise sysctl interface seems
wrong to me. We can bury the call inside libxenkexec itself for the time
being.

> For xc_version(), I am thinking to extend libxentoolcore to also include
> "stable xen API".
> 

If you can do without an xc handle, do you still need to call
xc_version?

Wei.

> Any opinion on the approach?
> 
> Cheers,
> 
> 
> [1] 
> https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=894bea9335f57b62cbded7b02ab7d58308b647d8