Andy Lutomirski <l...@kernel.org> writes:
> On Wed, May 20, 2020 at 12:17 PM Thomas Gleixner <t...@linutronix.de> wrote:
>>
>> Andy Lutomirski <l...@kernel.org> 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();
This really want's to use preempt_schedule_irq() as the above is racy
vs. need_resched().
> }
> }
> 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.
You still lose the debug checks. I'm working on it ...
Thanks,
tglx
