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

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

> On 7. Aug 2019, at 14:30, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 07/08/2019 13: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.
>>> ~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.

Thanks a lot for the prompt responses, everyone.

Yes, Xen is doing the right thing. But, I would not call it a Linux bug either. 
Hibernate/resume (rightfully) assumes that the underlying HW and the virtual 
subsystem and its capabilities have not changed during the guest's logical 
lifetime. The knob introduced in this patch goes along the same lines: allow an 
administrator to control which event channel ABI support level to expose in 
order to maintain a particular guest's view of the underlying HW and virtual 

> ~Andrew

Xen-devel mailing list



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