Re: [PATCHv1] xen/events/fifo: Handle linked events when closing a PIRQ port

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 09/16/2015 11:34 AM, David Vrabel wrote:
> On 16/09/15 16:26, Boris Ostrovsky wrote:
>> On 08/10/2015 01:16 PM, David Vrabel wrote:
>>> On 10/08/15 17:47, linux@eikelenboom.it wrote:
>>>> On 2015-08-10 16:24, David Vrabel wrote:
>>>>> Commit fcdf31a7c162de0c93a2bee51df4688ab0a348f8 (xen/events/fifo:
>>>>> Handle linked events when closing a port) did not handle closing a
>>>>> port bound to a PIRQ because these are closed from shutdown_pirq()
>>>>> which is called with interrupts disabled.
>>>>>
>>>>> Defer the close to a work queue where we can safely spin waiting for
>>>>> the LINKED bit to clear.  For simplicity, the close is always deferred
>>>>> even if it is not required (i.e., we're already in process context).
>>>>>
>>>>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>>>>> Cc: Ross Lagerwall <ross.lagerwall@citrix.com>
>>>>> ---
>>>>> Cc: Sander Eikelenboom <linux@eikelenboom.it>
>>>> Hi David,
>>>>
>>>> Tested your patch, don't know for sure but this doesn't seem to work
>>>> out.
>>>> I end up with this event channel error on dom0 boot.
>>>>
>>>> Which ends in state:
>>>> Name                                        ID   Mem VCPUs    State
>>>> Time(s)
>>>> (null)                                       0  1536     6     r-----
>>>>    183.8
>>>>
>>>> -- 
>>>> Sander
>>>>
>>>> (XEN) [2015-08-10 16:35:34.584] PCI add device 0000:0d:00.0
>>>> (XEN) [2015-08-10 16:35:34.891] PCI add device 0000:0c:00.0
>>>> (XEN) [2015-08-10 16:35:35.123] PCI add device 0000:0b:00.0
>>>> (XEN) [2015-08-10 16:35:35.325] PCI add device 0000:0a:00.0
>>>> (XEN) [2015-08-10 16:35:35.574] PCI add device 0000:09:00.0
>>>> (XEN) [2015-08-10 16:35:35.642] PCI add device 0000:09:00.1
>>>> (XEN) [2015-08-10 16:35:35.872] PCI add device 0000:05:00.0
>>>> (XEN) [2015-08-10 16:35:36.044] PCI add device 0000:06:01.0
>>>> (XEN) [2015-08-10 16:35:36.109] PCI add device 0000:06:02.0
>>>> (XEN) [2015-08-10 16:35:36.293] PCI add device 0000:08:00.0
>>>> (XEN) [2015-08-10 16:35:36.603] PCI add device 0000:07:00.0
>>>> (XEN) [2015-08-10 16:35:36.906] PCI add device 0000:04:00.0
>>>> (XEN) [2015-08-10 16:35:37.074] PCI add device 0000:03:06.0
>>>> (XEN) [2015-08-10 16:35:39.456] PCI: Using MCFG for segment 0000 bus
>>>> 00-ff
>>>> (XEN) [2015-08-10 16:35:49.623] d0: Forcing read-only access to MFN
>>>> fed00
>>>> (XEN) [2015-08-10 16:35:51.374] event_channel.c:472:d0v0 EVTCHNOP
>>>> failure: error -17
>>> This didn't happen on the test box I used but I can see it is possible
>>> to rebind a PIRQ whose close is still deferred.
>>>
>>> I'm going to revert fcdf31a7c162de0c93a2bee51df4688ab0a348f8
>>> (xen/events/fifo: Handle linked events when closing a port) for now.
>>
>> Any updates on these two patches? We started seeing this problem (stale
>> events) in our testing when onlining/offlining vcpus in heavily
>> oversubscribed guests.
> This is the last attempt I came up with -- using a tasklet to wait for the
> event to be unlinked.  I was worried that that tasklets could be punted
> to the ksoftirqd threads but haven't investigated this or come
> up with something else (perhaps a high priority tasklet instead?).

Since you are scheduling the tasklet not from an interrupt handler I 
believe it will run out of ksoftirqd in either case. In which case I 
think it is still possible that a PIRQ can be rebinded (rebound?) before 
the tasklet runs.

-boris