On Wed, Jun 21, 2023, at 8:14 AM, Per Bilse wrote:
> Some Xen hypercalls issued by dom0 guests may run for many 10s of
> seconds, potentially causing watchdog timeouts and other problems.
> It's rare for this to happen, but it does in extreme circumstances,
> for instance when shutting down VMs with very large memory allocations
> (> 0.5 - 1TB). These hypercalls are preemptible, but the fixes in the
> kernel to ensure preemption have fallen into a state of disrepair, and
> are currently ineffective. This patch brings things up to date by way of:
>
> 1) Update general feature selection from XEN_PV to XEN_DOM0.
> The issue is unique to dom0 Xen guests, but isn't unique to PV dom0s,
> and will occur in future PVH dom0s. XEN_DOM0 depends on either PV or PVH,
> as well as the appropriate details for dom0.
>
> 2) Update specific feature selection from !PREEMPTION to !PREEMPT.
> The following table shows the relationship between different preemption
> features and their indicators/selectors (Y = "=Y", N = "is not set",
> . = absent):
>
> | np-s | np-d | vp-s | vp-d | fp-s | fp-d
> CONFIG_PREEMPT_DYNAMIC N Y N Y N Y
> CONFIG_PREEMPTION . Y . Y Y Y
> CONFIG_PREEMPT N N N N Y Y
> CONFIG_PREEMPT_VOLUNTARY N N Y Y N N
> CONFIG_PREEMPT_NONE Y Y N N N N
>
> Unless PREEMPT is set, we need to enable the fixes.
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.
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.
2. Forget about trying to preempt a hypercall in the sense of scheduling from an interrupt. Instead teach the interrupt code to detect that it's in a preemptible hypercall and change RIP to a landing pad that does a cond_resched() and then resumes the hypercall.
I don't think the entry code should have a whole special preempt implementation just for this nasty special case.
--Andy