Deassigning irqfd and assigning back caused spurious interrupt. fix this
by clearing the counter on deassign. This is on top of davidel's patch
which makes clearing eventfd counter from modules possible.
Michael S. Tsirkin (2):
kvm: fix spurious interrupt with irqfd
kvm: do not store wqh in irqfd
virt/kvm/eventfd.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
On 01/13/2010 07:12 PM, Michael S. Tsirkin wrote:
> Deassigning irqfd and assigning back caused spurious interrupt. fix this
> by clearing the counter on deassign. This is on top of davidel's patch
> which makes clearing eventfd counter from modules possible.
>
Applied both, thanks.
--
error compiling committee.c: too many arguments to function
On Sun, Jan 17, 2010 at 02:42:50PM +0200, Avi Kivity wrote:
> On 01/13/2010 07:12 PM, Michael S. Tsirkin wrote:
>> Deassigning irqfd and assigning back caused spurious interrupt. fix this
>> by clearing the counter on deassign. This is on top of davidel's patch
>> which makes clearing eventfd counter from modules possible.
>>
>
> Applied both, thanks.
Hmm, I see this in kvm master. Avi/Marcelo, since this is a bugfix, can
you queue this patchset for 2.6.33 and 2.6.32 stable as well please?
> --
> error compiling committee.c: too many arguments to function
On 01/19/2010 04:52 PM, Michael S. Tsirkin wrote:
> On Sun, Jan 17, 2010 at 02:42:50PM +0200, Avi Kivity wrote:
>
>> On 01/13/2010 07:12 PM, Michael S. Tsirkin wrote:
>>
>>> Deassigning irqfd and assigning back caused spurious interrupt. fix this
>>> by clearing the counter on deassign. This is on top of davidel's patch
>>> which makes clearing eventfd counter from modules possible.
>>>
>>>
>> Applied both, thanks.
>>
> Hmm, I see this in kvm master. Avi/Marcelo, since this is a bugfix, can
> you queue this patchset for 2.6.33 and 2.6.32 stable as well please?
>
I'm uncomfortable with pushing Davide's patch into stable and possibly
causing regressions with unrelated applications. Can't a guest live
with a spurious interrupt? It's not like they're unknown.
--
error compiling committee.c: too many arguments to function
On Wed, Jan 20, 2010 at 04:10:37PM +0200, Avi Kivity wrote:
> On 01/19/2010 04:52 PM, Michael S. Tsirkin wrote:
>> On Sun, Jan 17, 2010 at 02:42:50PM +0200, Avi Kivity wrote:
>>
>>> On 01/13/2010 07:12 PM, Michael S. Tsirkin wrote:
>>>
>>>> Deassigning irqfd and assigning back caused spurious interrupt. fix this
>>>> by clearing the counter on deassign. This is on top of davidel's patch
>>>> which makes clearing eventfd counter from modules possible.
>>>>
>>>>
>>> Applied both, thanks.
>>>
>> Hmm, I see this in kvm master. Avi/Marcelo, since this is a bugfix, can
>> you queue this patchset for 2.6.33 and 2.6.32 stable as well please?
>>
>
> I'm uncomfortable with pushing Davide's patch into stable and possibly
> causing regressions with unrelated applications. Can't a guest live
> with a spurious interrupt?
Well guests mask/unmask vector on each interrupt, so this will trigger
an irq storm I think.
> It's not like they're unknown.
Depends on the device really.
In theory, if they trigger at an unfortunate time this could cause
crashes.
--
MST
On 01/20/2010 04:58 PM, Michael S. Tsirkin wrote:
>
>> I'm uncomfortable with pushing Davide's patch into stable and possibly
>> causing regressions with unrelated applications. Can't a guest live
>> with a spurious interrupt?
>>
> Well guests mask/unmask vector on each interrupt, so this will trigger
> an irq storm I think.
>
>
>> It's not like they're unknown.
>>
> Depends on the device really.
> In theory, if they trigger at an unfortunate time this could cause
> crashes.
>
>
I'd like confirmation on both of these before I push things to stable.
--
error compiling committee.c: too many arguments to function
On Wed, Jan 20, 2010 at 05:09:32PM +0200, Avi Kivity wrote:
> On 01/20/2010 04:58 PM, Michael S. Tsirkin wrote:
>>
>>> I'm uncomfortable with pushing Davide's patch into stable and possibly
>>> causing regressions with unrelated applications. Can't a guest live
>>> with a spurious interrupt?
>>>
>> Well guests mask/unmask vector on each interrupt, so this will trigger
>> an irq storm I think.
>>
>>
>>> It's not like they're unknown.
>>>
>> Depends on the device really.
>> In theory, if they trigger at an unfortunate time this could cause
>> crashes.
>>
>>
>
> I'd like confirmation on both of these before I push things to stable.
I have observed the interrupt storm. We end up with interrupt being
disabled. Crash is a theoretical issue.
--
MST
On Wed, 20 Jan 2010, Avi Kivity wrote:
> I'm uncomfortable with pushing Davide's patch into stable and possibly causing
> regressions with unrelated applications. Can't a guest live with a spurious
> interrupt? It's not like they're unknown.
Better material for .33 instead of stable, I agree.
- Davide