Re: Live update of Xenstore-stubdom

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]

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?

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

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]