Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: ieff94742:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-499-gf27bbf33e2-fm-20230619.001-gf27bbf33
Mime-Version: 1.0
Message-Id: <0ff85b95-f4c7-445c-b0e0-7368c182ee0b@app.fastmail.com>
In-Reply-To: <333138f8-9fbe-be5b-d125-12c9d3ed3eda@citrix.com>
References: <20230621151442.2152425-1-per.bilse@citrix.com>
 <7fbad052-4c4a-4a49-913d-ea836c180dc2@app.fastmail.com>
 <333138f8-9fbe-be5b-d125-12c9d3ed3eda@citrix.com>
Date:   Wed, 21 Jun 2023 16:42:44 -0700
From:   "Andy Lutomirski" <luto@kernel.org>
To:     "Per Bilse" <Per.Bilse@citrix.com>,
        "Thomas Gleixner" <tglx@linutronix.de>,
        "Ingo Molnar" <mingo@redhat.com>, "Borislav Petkov" <bp@alien8.de>,
        "Dave Hansen" <dave.hansen@linux.intel.com>,
        "the arch/x86 maintainers" <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        "Juergen Gross" <jgross@suse.com>,
        "Stefano Stabellini" <sstabellini@kernel.org>,
        "Oleksandr Tyshchenko" <oleksandr_tyshchenko@epam.com>,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
        "moderated list:XEN HYPERVISOR INTERFACE" 
        <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] Updates to Xen hypercall preemption
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On Wed, Jun 21, 2023, at 12:05 PM, Per Bilse wrote:
> On 6/21/2023 5:27 PM, Andy Lutomirski wrote:
>> This code is a horrible mess, with and without your patches.  I think=
 that, if this were new, there's no way it would make it in to the kerne=
l.
>
> Hi Andy, and many thanks for your frank assessments.  Generally, this
> is indeed somewhat old code, first introduced in 2015 by way of commit
> fdfd811ddde3.  There's more information in the notes to that, and it's
> maybe worth noting that we're not trying to introduce anything new,
> merely fix what various commits since then have broken.
>
>> I propose one of two rather radical changes:
>>=20
>> 1. (preferred) Just delete all of it and make support for dom0 requir=
e either full or dynamic preempt, and make a dynamic preempt kernel boot=
ing as dom0 run as full preempt.
>
> Personally I think that's a good idea; a machine so limited in resourc=
es
> that a fully preemptible dom0 kernel would be a problem wouldn't work =
as
> a Xen server anyway.  Having said that, what to do about this isn't
> really in my hands; the issues came to light because the kernel for
> Citrix's XenServer product is being upgraded, and it was considered in
> everybody's interest to upstream the fixes.  I'll see what I can do.

This isn=E2=80=99t actually a resource thing. It=E2=80=99s a distro thin=
g.

Historically, full preempt was a config option only, and distros, for wh=
atever reason, often shipped kernels with full preempt disabled.  (There=
 we probably decent reasons. There may still be decent reasons.). And Xe=
n needed to work on these kernels.  Hence the mess.

But Linux recently gained the ability to build a kernel that, by default=
, is not full preempt but can be switched *at boot or runtime* to full p=
reempt. And distros should ship *that* (or a kernel that does have full =
preempt by default).

So let=E2=80=99s just make Xen PV dom0 depend on this. It wasn=E2=80=99t=
 an option a couple years ago. Now it is.

>
> Best,
>
>    -- Per