xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Elnikety, Eslam" <elnikety@amazon.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Julien Grall <julien.grall@arm.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Woodhouse, David" <dwmw@amazon.co.uk>
Subject: Re: [Xen-devel] [PATCH] evtchn: make support for different ABIs tunable
Date: Wed, 7 Aug 2019 13:27:09 +0000	[thread overview]
Message-ID: <79556E3F-65AD-42F4-96A0-8EEB99D59398@amazon.com> (raw)
In-Reply-To: <6a5f6fa6-d387-a665-47f1-e5a1b0534a6e@suse.com>


[-- Attachment #1.1: Type: text/plain, Size: 2276 bytes --]



On 7. Aug 2019, at 14:20, Jan Beulich <jbeulich@suse.com<mailto:jbeulich@suse.com>> wrote:

On 07.08.2019 14:07,  Elnikety, Eslam  wrote:
On 7. Aug 2019, at 13:40, Andrew Cooper <andrew.cooper3@citrix.com<mailto:andrew.cooper3@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.
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

I think a re-write for the commit message is in order, given that the distinction between boot and resume kernels was not clear. I will do that, along with other changes if needed, subject to the maintainers being happy with the patch at a high level.

In principle, we can instruct the boot kernel to not use FIFO. Yet, this will be needed when resuming on Xen >= 4.4, but not needed when resuming on Xen < 4.4. I think this is grounds to introduce the knob.

Thanks,
Eslam

[-- Attachment #1.2: Type: text/html, Size: 9182 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

  reply	other threads:[~2019-08-07 13:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-07 11:20 [Xen-devel] [PATCH] evtchn: make support for different ABIs tunable Eslam Elnikety
2019-08-07 11:40 ` Andrew Cooper
2019-08-07 12:04   ` Woodhouse, David
2019-08-07 12:18     ` Jan Beulich
2019-08-07 12:24     ` Andrew Cooper
2019-08-07 12:07   ` Elnikety, Eslam
2019-08-07 12:20     ` Jan Beulich
2019-08-07 13:27       ` Elnikety, Eslam [this message]
2019-08-07 12:30     ` Andrew Cooper
2019-08-07 13:01       ` Elnikety, Eslam
2019-08-07 13:41 ` Andrew Cooper
2019-08-07 14:30   ` Jan Beulich
2019-08-07 15:00     ` Andrew Cooper
2019-08-07 15:08       ` Jan Beulich
2019-08-07 15:57         ` Andrew Cooper
2019-08-07 16:03           ` Jan Beulich
2019-08-14 12:51             ` George Dunlap
2019-08-14 13:02               ` Andrew Cooper
2019-08-19 12:16                 ` Eslam Elnikety
2019-08-07 15:43   ` Elnikety, Eslam
2019-08-07 14:35 ` Jan Beulich
2019-08-07 14:41   ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=79556E3F-65AD-42F4-96A0-8EEB99D59398@amazon.com \
    --to=elnikety@amazon.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=dwmw@amazon.co.uk \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien.grall@arm.com \
    --cc=konrad.wilk@oracle.com \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).