Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.10.2026 10:05, Roger Pau Monné wrote:
> On Fri, Oct 02, 2026 at 09:55:09AM +0200, Jan Beulich wrote:
>> On 02.10.2026 09:48, Roger Pau Monné wrote:
>>> On Fri, Oct 02, 2026 at 07:45:07AM +0200, Jan Beulich wrote:
>>>> On 01.10.2026 16:27, Roger Pau Monne wrote:
>>>>> --- a/xen/arch/x86/domain.c
>>>>> +++ b/xen/arch/x86/domain.c
>>>>> @@ -813,8 +813,6 @@ static bool emulation_flags_ok(const struct domain 
>>>>> *d, uint32_t emflags)
>>>>>  void __init arch_init_idle_domain(struct domain *d)
>>>>>  {
>>>>>      static const struct arch_csw idle_csw = {
>>>>> -        .from = paravirt_ctxt_switch_from,
>>>>> -        .to   = paravirt_ctxt_switch_to,
>>>>>          .tail = idle_loop,
>>>>>      };
>>>>
>>>> Leaving NULL pointers around isn't a good thing, though. May I suggest to
>>>> at least poison the pointers then?
>>>
>>> I don't mind doing so, but I don't think we usually do that for other
>>> hook structures, ie: hvm_function_table for example doesn't poison
>>> unset hooks (and it possibly can't, because there are .hook != NULL
>>> checks).
>>>
>>> TBH I'm missing a benefit of the poisoning here.  Using NULL or a
>>> poisoned value will both trigger a page-fault, and NULL has the
>>> benefit of callers easily checking whether the hook is set.
>>
>> NULL in the context of a HVM vCPU will #PF. NULL in the context of a PV
>> one may not, depending on what the guest may have put there.
> 
> It still feels a bit arbitrary to do here but not in other places,

We should imo resolve this by replacing NULLs wherever hooks could, due
to other issues, end up "in sight" on paths reachable for PV guests. This
would then also cover potential speculation along such paths.

> but never mind, I will adjust and send v2.

Thanks.

Jan