Live update of Xenstore-stubdom

* Live update of Xenstore-stubdom
@ 2022-01-06 14:33 Juergen Gross
  2022-01-06 16:59 ` Marek Marczykowski-Górecki
  0 siblings, 1 reply; 3+ messages in thread
From: Juergen Gross @ 2022-01-06 14:33 UTC (permalink / raw)
  To: xen-devel
  Cc: Julien Grall, Jan Beulich, Andrew Cooper, George Dunlap,
	Ian Jackson, Anthony PERARD, Roger Pau Monné

[-- Attachment #1.1.1: Type: text/plain, Size: 3375 bytes --]

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.

A nice way to do that would be to use a 9pfs PV device, but this is
problematic across the kexec in the domain, as there is no Xenstore
available for any additional frontend-backend communication at that
time.

The 9pfs PV protocol as defined today needs at least 3 pages granted by
the frontend to the backend (the main parameter page, and at least 1
ring page for each direction of communication). For better performance
even more pages might be desirable (the 9pfs PV protocol allows for up
to 256 pages for each direction of communication, all file data is going
through those ring pages).

For using 9pfs I'd need to either extend the current PV protocol in
order to support reconfiguration of the PV device without needing
Xenstore (so no change of the frontend state required), or the 9pfs
configuration would need to be kept across kexec, including the PFNs of
the granted pages (this could be achieved e.g. via a fixed PFN range
like it is done for the PV console ring page today).

Another possibility would be to extend the current pvcalls interface
to support file operations. This would require "only" some additional
commands (read, write, stat, ...) and could work easily with a single
ring page (reads and writes would use grants, of course). OTOH this
would add basically a similar functionality as the 9pfs PV device.

This whole file access scheme could even be extended to other use
cases, like driver domains and other stubdoms, in order to have the
possibility to produce logs of all infrastructure domains at a central
place.

Per default I'd extend the console daemon to act as a backend (either
9pfs or pvcalls), but that should be configurable in order to allow e.g.
for a logging stubdom, too.

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

Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread