public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Davide Libenzi <davidel@xmailserver.org>,
	kvm@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] kvm: fix spurious interrupt with irqfd
Date: Tue, 19 Jan 2010 16:03:18 +0200	[thread overview]
Message-ID: <4B55BBA6.2050806@redhat.com> (raw)
In-Reply-To: <4B55B2B8.5090105@siemens.com>

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


  parent reply	other threads:[~2010-01-19 14:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1263402727.git.mst@redhat.com>
2010-01-13 17:12 ` [PATCH 1/2] kvm: fix spurious interrupt with irqfd Michael S. Tsirkin
2010-01-19 13:25   ` Jan Kiszka
2010-01-19 13:48     ` Michael S. Tsirkin
2010-01-19 14:03       ` Jan Kiszka
2010-01-19 14:04         ` Michael S. Tsirkin
2010-01-19 14:23           ` Jan Kiszka
2010-01-19 14:29             ` Michael S. Tsirkin
2010-01-19 14:03     ` Avi Kivity [this message]
2010-01-13 17:12 ` [PATCH 2/2] kvm: do not store wqh in irqfd Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B55BBA6.2050806@redhat.com \
    --to=avi@redhat.com \
    --cc=davidel@xmailserver.org \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox