kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Avi Kivity <avi@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>, kvm <kvm@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
Date: Mon, 24 Oct 2011 14:06:08 +0200	[thread overview]
Message-ID: <4EA554B0.7030808@siemens.com> (raw)
In-Reply-To: <4EA54759.902@redhat.com>

On 2011-10-24 13:09, Avi Kivity wrote:
> On 10/24/2011 12:19 PM, Jan Kiszka wrote:
>>>
>>> With the new feature it may be worthwhile, but I'd like to see the whole
>>> thing, with numbers attached.
>>
>> It's not a performance issue, it's a resource limitation issue: With the
>> new API we can stop worrying about user space device models consuming
>> limited IRQ routes of the KVM subsystem.
>>
> 
> Only if those devices are in the same process (or have access to the
> vmfd).  Interrupt routing together with irqfd allows you to disaggregate
> the device model.  Instead of providing a competing implementation with
> new limitations, we need to remove the limitations of the old
> implementation.

That depends on where we do the cut. Currently we let the IRQ source
signal an abstract edge on a pre-allocated pseudo IRQ line. But we
cannot build correct MSI-X on top of the current irqfd model as we lack
the level information (for PBA emulation). *) So we either need to
extend the existing model anyway -- or push per-vector masking back to
the IRQ source. In the latter case, it would be a very good chance to
give up on limited pseudo GSIs with static routes and do MSI messaging
from external IRQ sources to KVM directly.

But all those considerations affect different APIs than what I'm
proposing here. We will always need a way to inject MSIs in the context
of the VM as there will always be scenarios where devices are better run
in that very same context, for performance or simplicity or whatever
reasons. E.g., I could imagine that one would like to execute an
emulated IRQ remapper rather in the hypervisor context than
"over-microkernelized" in a separate process.

Jan

*) Realized this while trying to generalize the proposed MSI-X MMIO
acceleration for assigned devices to arbitrary device models, vhost-net,
and specifically vfio.

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

  reply	other threads:[~2011-10-24 12:06 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-21  9:19 [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips Jan Kiszka
2011-10-21  9:42 ` Sasha Levin
2011-10-21 11:06 ` Michael S. Tsirkin
2011-10-21 11:51   ` Jan Kiszka
2011-10-21 12:04     ` Michael S. Tsirkin
2011-10-21 13:00       ` Jan Kiszka
2011-10-24  9:45 ` Avi Kivity
2011-10-24 10:19   ` Jan Kiszka
2011-10-24 11:09     ` Avi Kivity
2011-10-24 12:06       ` Jan Kiszka [this message]
2011-10-24 12:43         ` Michael S. Tsirkin
2011-10-24 13:11           ` Jan Kiszka
2011-10-24 13:43             ` Jan Kiszka
2011-10-24 14:40               ` Michael S. Tsirkin
2011-10-24 15:00                 ` Jan Kiszka
2011-10-24 16:05                   ` Michael S. Tsirkin
2011-10-24 16:10                     ` Jan Kiszka
2011-10-24 17:05                       ` Michael S. Tsirkin
2011-10-24 17:23                         ` Michael S. Tsirkin
2011-10-25  7:24                           ` Jan Kiszka
2011-10-25 11:20                             ` Michael S. Tsirkin
2011-10-25 11:41                               ` Jan Kiszka
2011-10-25 12:05                                 ` Michael S. Tsirkin
2011-10-25 12:21                                   ` Jan Kiszka
2011-10-25 13:29                                     ` Michael S. Tsirkin
2011-10-24 14:25             ` Michael S. Tsirkin
2011-10-25  7:56         ` Avi Kivity

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=4EA554B0.7030808@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=mtosatti@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;
as well as URLs for NNTP newsgroup(s).