kvm: fix spurious interrupt with irqfd
cover kvm: fix spurious interrupt with irqfd
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(-)
Avi Kivity
AppliedQuoted 4 lines · Michael S. Tsirkin
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.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 7 lines · Avi Kivity
Quoted 4 lines · Michael S. Tsirkin
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?
Quoted 2 lines
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 9 lines · Michael S. Tsirkin
Quoted 7 lines · Avi Kivity
Quoted 5 lines · Michael S. Tsirkin
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.
Quoted 5 lines
Quoted 2 lines
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.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 12 lines · Avi Kivity
Quoted 11 lines · Michael S. Tsirkin
Quoted 9 lines · Avi Kivity
Quoted 5 lines · Michael S. Tsirkin
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 1 line
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.
Signature · 1 line
MST
Quoted 9 lines · Michael S. Tsirkin
Quoted 5 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 12 lines · Avi Kivity
Quoted 11 lines · Michael S. Tsirkin
Quoted 5 lines
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.
Quoted 2 lines
It's not like they're unknown.
Quoted 7 lines
Quoted 5 lines
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.
Signature · 1 line
MST
Quoted 3 lines · Avi Kivity
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