Re: [patch V6 10/37] x86/entry: Switch XEN/PV hypercall entry to IDTENTRY
From: Andy Lutomirski
Date: Wed May 20 2020 - 19:21:53 EST
On Wed, May 20, 2020 at 12:17 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>
> Andy Lutomirski <luto@xxxxxxxxxx> writes:
> > Andrew Cooper pointed out that there is too much magic in Xen for this
> > to work. So never mind.
>
> :)
>
> But you made me stare more at that stuff and I came up with a way
> simpler solution. See below.
I like it, but I bet it can be even simpler if you do the
tickle_whatever_paulmck_call_it() change:
> +__visible noinstr void xen_pv_evtchn_do_upcall(struct pt_regs *regs)
> +{
> + struct pt_regs *old_regs;
> + bool inhcall;
> +
> + idtentry_enter(regs);
> + old_regs = set_irq_regs(regs);
> +
> + run_on_irqstack(__xen_pv_evtchn_do_upcall, NULL, regs);
> +
> + set_irq_regs(old_regs);
> +
> + inhcall = get_and_clear_inhcall();
> + __idtentry_exit(regs, inhcall);
> + restore_inhcall(inhcall);
How about:
inhcall = get_and_clear_inhcall();
if (inhcall) {
if (!WARN_ON_ONCE((regs->flags & X86_EFLAGS_IF) || preempt_count()) {
local_irq_enable();
cond_resched();
local_irq_disable();
}
}
restore_inhcall(inhcall);
idtentry_exit(regs);
This could probably be tidied up by having a xen_maybe_preempt() that
does the inhcall and resched mess.
The point is that, with the tickle_nohz_ stuff, there is nothing
actually preventing IRQ handlers from sleeping as long as they aren't
on the IRQ stack and as long as the interrupted context was safe to
sleep in.
--Andy