On 07/08/2019 13:07, Elnikety, Eslam wrote: >> On 7. Aug 2019, at 13:40, Andrew Cooper <andrew.coop...@citrix.com> 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. >> >> ~Andrew > > After resuming (i.e., Linux's software_resume), the guest will indeed > continue to use 2L. However, Xen has already done evtchn_fifo_init_control as > part of the boot kernel init (before the guest's software_resume). Then, we > reach the point where guest assumes 2L and Xen assumes FIFO.
With Davids explanation, I now understand the problem. However for clarity, it is probably worth making a correction here. It isn't Xen which does evtchn_fifo_init_control(). It is the "boot" kernel issuing EVTCHNOP_init_control hypercall which switches the domain from 2L mode into FIFO mode. Xen is doing exactly as it was instructed. The underlying bug is a mismatch in behaviour between the "boot" kernel and the on-disk kernel/state. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
