Re: Kexec and libxenctlr.so

[Jürgen Groß <jgross@xxxxxxxx>]

On 12.06.20 10:25, Julien Grall wrote:
> Hi Juergen,
>
> On 12/06/2020 05:25, Jürgen Groß wrote:
> > On 11.06.20 18:00, Julien Grall wrote:
> > > On 11/06/2020 16:35, Jürgen Groß wrote:
> > > > 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).
> > > AFAICT, hypfs allows you to modify runtime parameters which is not 
> > > required for kexec.
> > Well, and? kexec won't use this functionality.
> >
> > libxenctrl allows to create domains, which isn't required for kexec.
> > And kexec doesn't do it.
> And so does libc... so that was clear not my point...
>
> > We could still have the entry points for that functionality in
> > libxenexec, which could use libxenhypfs (and maybe others).
> >
> > > Such feature could be undesirable in some setup and therefore I don't 
> > > think this is acceptable to impose that for kexec.
> > If we really have setups where this would be an issue we'd need
> > to modify the flask integration of hypfs to be able to disallow
> > write access to hypfs. Or we could even add per-node access rights.
> ... Not everyone wants to use flask and I don't think this should be a 
> condition to forbid runtime configuration change for all the system.
> You may want to set a minimal Xen with no runtime configuration support 
> and no flask. Yet you may want to kexec for updating your Xen.
> Even with the runtime bits removed, I still don't think we should impose 
> to build hypfs in the hypervisor given there are already always built 
> hypercalls.
There might be a misunderstanding here.

I just wanted to point out that in case you need a new stable interface
between kexec and the hypervisor you could consider using hypfs for that
purpose instead of introducing a new hypercall.

In case all hypercalls are already present, then fine.

If not I don't see why introducing a new hypercall should be preferred
over using an existing mechanism.


Juergen