[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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, but
never mind, I will adjust and send v2.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.