[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] evtchn: make support for different ABIs tunable

On 07.08.2019 14:04,  Woodhouse, David  wrote:
On Wed, 2019-08-07 at 12:40 +0100, Andrew Cooper wrote:
On 07/08/2019 12:20, Eslam Elnikety wrote:
Adding support for FIFO event channel ABI was first introduced in Xen 4.4
(see 88910061ec6). Make this support tunable, since the choice of which
event channel ABI has implications for hibernation. Consider resuming a
pre Xen 4.4 hibernated Linux guest. The guest boot kernel defaults to FIFO
ABI, whereas the resume kernel assumes 2L. This, in turn, results in Xen
and the resumed kernel talking past each other (due to different protocols
FIFO vs 2L).

I'm afraid I don't follow.

We have a Linux kernel which knows about FIFO, which was first booted on
Xen < 4.4, so configured 2L mode.

It is then suspended, and resumed on a newer Xen >= 4.4.  The guest now
has a choice between 2L mode, and FIFO mode.

What is the problem?

When resuming, the guest in question should continue to use 2L mode,
because that is what it was using previously.

On resume, the guest first boots a Linux kernel (the 'boot' kernel).
That kernel then loads the previous state (the 'resumed' kernel) from
disk and then transfers control to it.

I believe the problem occurs when the boot kernel sees and enables FIFO
mode, then transfers control to the resumed kernel which is expecting

I wonder if treating it more like a kexec and doing SHUTDOWN_soft_reset
in the handover might be a viable long-term approach (and deal with
other KASLR-related problems). Not that soft reset currently resets
this AFAICT at a quick glance, but maybe it should?

Oh, definitely, if it doesn't already. Soft-reset should really do what
its name says and put state back to what it was initially.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.