Michael S. Tsirkin wrote: > kvm didn't clear irqfd counter on deassign, as a result we could get a > spurious interrupt when irqfd is assigned back. this leads to poor > performance and, in theory, guest crash. > > Signed-off-by: Michael S. Tsirkin <[email protected]> > --- > virt/kvm/eventfd.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c > index 62e4cd9..a9d3fc6 100644 > --- a/virt/kvm/eventfd.c > +++ b/virt/kvm/eventfd.c > @@ -72,12 +72,13 @@ static void > irqfd_shutdown(struct work_struct *work) > { > struct _irqfd *irqfd = container_of(work, struct _irqfd, shutdown); > + u64 cnt; > > /* > * Synchronize with the wait-queue and unhook ourselves to prevent > * further events. > */ > - remove_wait_queue(irqfd->wqh, &irqfd->wait); > + eventfd_ctx_remove_wait_queue(irqfd->eventfd, &irqfd->wait, &cnt); > > /* > * We know no new events will be scheduled at this point, so block
For kvm-kmod, I'm fighting with compat support for eventfd_ctx_remove_wait_queue. I basically have a solution for kernels with CONFIG_KPROBES enabled (I need to look up unexported __wake_up_locked[_key]), but there will also be target kernels that do not have this. So there are three options for that case: - Warn the user and fall back to the old racy approach - (Somehow) disable KVM subsystems that use eventfd - Refuse to start KVM As far as I understood, irqfd is interesting for device assignment and now also for vhost, right? What about ioeventfd? I just wonder how broad the impact of a broken or non-existent eventfd subsystem for kvm-kmod is. Any thoughts welcome. Jan PS: If anyone forgot why Avi handed over this job, you should now remember why. :) -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
