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

["Roger Pau Monné" <roger.pau@citrix.com>]

On Thu, Nov 08, 2018 at 05:32:02AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 12:29, <roger.pau@citrix.com> wrote:
> > On Thu, Nov 08, 2018 at 02:55:56AM -0700, Jan Beulich wrote:
> >> >>> On 07.11.18 at 18:15, <roger.pau@citrix.com> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel