Re: Live update of Xenstore-stubdom

[Juergen Gross <jgross@xxxxxxxx>]

On 06.01.22 17:59, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 06, 2022 at 03:33:49PM +0100, Juergen Gross wrote:
> > I'm currently thinking how to implement live update of Xenstore-stubdom.
> >
> > I should note that my plan is to support live update for a Xenstore PVH
> > stubdom only, as kexec functionality is much easier to implement for
> > that case.
> >
> > The main problem is to transfer the Xenstore state to the new instance.
> >
> > Originally my idea was to keep the state in memory and hand it over to
> > the new kernel as a module. This would probably work, but there is one
> > basic problem with that approach: the Xenstore domain might need quite
> > some additional memory to hold the module (roughly up to twice the
> > memory it has in use when starting the live update).
> >
> > As a result the live update sequence would need to:
> >
> > 1. increase the maximum allowed memory of the Xenstore domain
> > 2. allocate additional memory for the module
> > 3. create the module
> > 4. kexec to the new kernel
> > 5. build the Xenstore from the module
> > 6. free the module memory
> > 7. decrease the max memory of the domain again
> >
> > The first and last step would need to be done by xenstore-control in
> > dom0, while all the other steps would be done in the Xenstore-stubdom.
> >
> > As an alternative I was thinking to add some basic file operations to
> > Xenstore-stubdom. This would have the additional benefit of having an
> > easy way to add Xenstore logging support to the stubdom without the risk
> > to lose logging data when using the console for that purpose.
> What specifically is wrong about using console for logging? Rate limits?
Today there are two problems related to that:

1. The Mini-OS console driver is not waiting for the backend to drain
   the ring buffer, so any messages sent with a full buffer are just
   discarded. This can be changed, of course.

2. The console backend has an "all or nothing" logging functionality,
   i.e. it is not possible to control logging of specific domains
   only.

> > So what are the thoughts for the way to go with Xenstore-stubdom live
> > update? Should I use stubdom memory for the state, or should I go with a
> > file based approach (and if yes, 9pfs or pvcalls based)?
> Personally, I'd go with memory, as IMHO it the cleanest design from
> disaggregation point of view (what was in stubomain, remains in
> stubdomain, no extra external interface necessary).
Thanks, noted.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature