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

[Julien Grall <julien.grall@arm.com>]

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel