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

[Roger Pau Monné <roger@xxxxxxxxxxxxxx>]

On Fri, Oct 02, 2026 at 11:35:40AM +0200, Jan Beulich wrote:
> On 02.10.2026 11:29, Roger Pau Monné wrote:
> > On Fri, Oct 02, 2026 at 11:23:17AM +0200, Roger Pau Monné wrote:
> >> On Fri, Oct 02, 2026 at 10:09:02AM +0200, Jan Beulich wrote:
> >>> 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.
> >>
> >> FTAOD, I plan to introduce a poison value using a non-canonical
> >> address, ie:
> >>
> >> #define POINTER_POISON ((void *)0xDEAD0000DEAD0000UL)
> > 
> > s/POINTER_POISON/FUNCTION_POISON/
> 
> Sure, if you think none of the present poisoning values we have is good to
> reuse here.

They maybe could, but I assumed we wanted differentiation between this
usage and ZERO_BLOCK_PTR for example.

Thanks, Roger.