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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.08.2019 14:07,  Elnikety, Eslam  wrote:
> > On 7. Aug 2019, at 13:40, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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.
> 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.
This involvement of two distinct kernels wasn't obvious at all from
the initial posting, despite the use of the terms "guest boot kernel"
and "resumed kernel". In any event - isn't this an issue to be solved
between the two kernels, without (as far as possible) Xen's
involvement, and without restricting guest capabilities?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel