Re: [PATCH 1/2] kvm: fix spurious interrupt with irqfd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/19/2010 03:25 PM, Jan Kiszka wrote:

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.


Since vhost is only a performance option (and there isn't a vhost-kmod) and device assignment wants a new kernel anyway (and only applies to a small subset of users), I think it's okay to drop it from kvm-kmod. It should be sufficient to return 0 from KVM_CHECK_EXCEPTION and substitute some stubs for the functions.

ioeventfd/irqfd are useful for inter-guest wakeups, but there isn't any public code for that that I'm aware of.

PS: If anyone forgot why Avi handed over this job, you should now
remember why. :)

It's only going to get more difficult, I'm afraid. The list of old kernels keeps growing and we're going to depend on core kernel functionality more and more.

Luckily for me you accepted in time...

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux