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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Roger,

On 11/8/18 11:44 AM, Roger Pau Monné wrote:
> On Thu, Nov 08, 2018 at 11:42:35AM +0000, Julien Grall wrote:
> > Hi,
> >
> > Sorry to jump in the conversation late.
> >
> > On 11/8/18 11:29 AM, Roger Pau Monné wrote:
> > > > 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.
> > I can't see how the recursion could happen on Arm. So is it an x86 issue?
> This is not an issue with the current code, I was just discussing with
> Jan how to properly implement vPCI long running operations that need
> to be preempted.
To give more context on my question, we are looking at handling 
preemption on Arm in some long running operations (e.g cache flush) 
without having to worry about returning to guest.
I am thinking something along the following on Arm in a loop.

for ( .... )
{
   do_action
   if ( try_reschedule )
   {
        raise_softirq(SCHEDULE_SOFTIRQ);
        do_softirq();
   }
}

This would require to have no lock taken but I think it would work on 
Arm for any long operations. So I am quite interested on the result on 
the discussions here.
Cheers,

--
Julien Grall

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