Re: [Xen-devel] [PATCH v3 5/7] vpci: fix execution of long running operations

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Nov 08, 2018 at 05:32:02AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 12:29, <roger.pau@xxxxxxxxxx> wrote:
> > On Thu, Nov 08, 2018 at 02:55:56AM -0700, Jan Beulich wrote:
> >> >>> On 07.11.18 at 18:15, <roger.pau@xxxxxxxxxx> wrote:
> >>  Then if the blocked bit is not set the call to do_softirq
> >> > would be recurred, thus probably leading to a stack overflow if
> >> > there's enough pending work. ie:
> >> > 
> >> > <process work>
> >> >  <do_softirq>
> >> >          <process work>
> >> >                  <do_softirq>
> >> >                          <...>
> >> 
> >> Why would that be? The do_softirq() invocation sits on the exit-
> >> to-guest path, explicitly avoiding any such nesting unless there
> >> was a do_softirq() invocation somewhere in a softirq handler.
> > 
> > It sits on an exit-to-guest path, but the following chunk:
> > 
> > raise_softirq(SCHEDULE_SOFTIRQ);
> > do_softirq();
> > 
> > Would prevent the path from ever reaching the exit-to-guest and
> > nesting on itself, unless the vCPU is marked as blocked, which
> > prevents it from being scheduled thus avoiding this recursion.
> 
> It would, indeed, but emphasis is on the subjunctive unless
> you have an example of such malformed code. I'm not
> aware of any, and my earlier comments also didn't suggest to
> introduce such. Perhaps I'm simply missing part of what you
> think you see?

Maybe, I think I'm also lost in this discussion because we seem to
agree.

My point would be that on x86 I think the only way to have preemptible
long-running operations inside of Xen is to block the guest vCPU and
run them in a tasklet, or at least this seems the less invasive one.

Do you still have objections to this patch/approach?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel