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 kernel.
>
> 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:
>>
>> 1. (preferred) Just delete all of it and make support for dom0 require either full or dynamic preempt, and make a dynamic preempt kernel booting as dom0 run as full preempt.
>
> Personally I think that's a good idea; a machine so limited in resources
> 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’t actually a resource thing. It’s a distro thing.
Historically, full preempt was a config option only, and distros, for whatever reason, often shipped kernels with full preempt disabled. (There we probably decent reasons. There may still be decent reasons.). And Xen 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 preempt. And distros should ship *that* (or a kernel that does have full preempt by default).
So let’s just make Xen PV dom0 depend on this. It wasn’t an option a couple years ago. Now it is.
>
> Best,
>
> -- Per