All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Avi Kivity <avi@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [RFC][PATCH 0/2] uq/master: Basic MSI support for in-kernel irqchip mode
Date: Wed, 28 Mar 2012 18:00:03 +0200	[thread overview]
Message-ID: <4F733583.9060100@siemens.com> (raw)
In-Reply-To: <20120328154309.GB20176@redhat.com>

On 2012-03-28 17:43, Michael S. Tsirkin wrote:
> On Wed, Mar 28, 2012 at 01:36:15PM +0200, Jan Kiszka wrote:
>> On 2012-03-28 13:31, Michael S. Tsirkin wrote:
>>>>>>> Also, how would this support irqfd in the future? Will we have to
>>>>>>> rip it all out and replace with per-device tracking that we
>>>>>>> have today?
>>>>>>
>>>>>> Irqfd and kvm device assignment will require additional interfaces (of
>>>>>> the kvm core in QEMU) via which you will be able to request stable
>>>>>> routes from such sources to specified MSIs. That will be widely
>>>>>> orthogonal to what is done in these patches here.
>>>>>
>>>>> Yes but not exactly as they will conflict for resources, right?
>>>>> How do you plan to solve this?
>>>>
>>>> As done in my original series: If a static route requires a pseudo GSI
>>>> and there are none free, we simply flush the dynamic MSI routes.
>>>
>>> Right. So static routes take precedence. This means that in effect
>>> we will have two APIs in qemu: for fast MSIs and for slow ones,
>>> the advantage of the slow APIs being that they are easier to use,
>>> right?
>>
>> We will have two APIs depending on the source of the MSI. Special
>> sources are the exception while emulated ones are the majority. And for
>> the latter we should try very hard to keep things simple and clean.
>>
>> Jan
> 
> I assume this means yes :) So how about we replace the hash table with a
> single GSI reserved for this purpose, and use that for each interrupt?
> This will work fine for slow paths such as hotplug controller, yes it
> will be slow but *predictably* slow.

AHCI, HDA, virtio-block, and every other userspace MSI user will suffer
- I can't imagine you really want this. :)

> 
> Fast path will use static GSIs like qemu-kvm does.

Nope, qemu-kvm hooks deeply into the MSI layer to track vectors. I don't
believe we want this upstream. It also doesn't work for non-PCI MSI
(HPET on x86, try -global hpet.timers=4 -global hpet.msi=on with Linux
guests).

Jan

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

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC][PATCH 0/2] uq/master: Basic MSI support for in-kernel irqchip mode
Date: Wed, 28 Mar 2012 18:00:03 +0200	[thread overview]
Message-ID: <4F733583.9060100@siemens.com> (raw)
In-Reply-To: <20120328154309.GB20176@redhat.com>

On 2012-03-28 17:43, Michael S. Tsirkin wrote:
> On Wed, Mar 28, 2012 at 01:36:15PM +0200, Jan Kiszka wrote:
>> On 2012-03-28 13:31, Michael S. Tsirkin wrote:
>>>>>>> Also, how would this support irqfd in the future? Will we have to
>>>>>>> rip it all out and replace with per-device tracking that we
>>>>>>> have today?
>>>>>>
>>>>>> Irqfd and kvm device assignment will require additional interfaces (of
>>>>>> the kvm core in QEMU) via which you will be able to request stable
>>>>>> routes from such sources to specified MSIs. That will be widely
>>>>>> orthogonal to what is done in these patches here.
>>>>>
>>>>> Yes but not exactly as they will conflict for resources, right?
>>>>> How do you plan to solve this?
>>>>
>>>> As done in my original series: If a static route requires a pseudo GSI
>>>> and there are none free, we simply flush the dynamic MSI routes.
>>>
>>> Right. So static routes take precedence. This means that in effect
>>> we will have two APIs in qemu: for fast MSIs and for slow ones,
>>> the advantage of the slow APIs being that they are easier to use,
>>> right?
>>
>> We will have two APIs depending on the source of the MSI. Special
>> sources are the exception while emulated ones are the majority. And for
>> the latter we should try very hard to keep things simple and clean.
>>
>> Jan
> 
> I assume this means yes :) So how about we replace the hash table with a
> single GSI reserved for this purpose, and use that for each interrupt?
> This will work fine for slow paths such as hotplug controller, yes it
> will be slow but *predictably* slow.

AHCI, HDA, virtio-block, and every other userspace MSI user will suffer
- I can't imagine you really want this. :)

> 
> Fast path will use static GSIs like qemu-kvm does.

Nope, qemu-kvm hooks deeply into the MSI layer to track vectors. I don't
believe we want this upstream. It also doesn't work for non-PCI MSI
(HPET on x86, try -global hpet.timers=4 -global hpet.msi=on with Linux
guests).

Jan

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

  reply	other threads:[~2012-03-28 16:00 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-21 23:17 [RFC][PATCH 0/2] uq/master: Basic MSI support for in-kernel irqchip mode Jan Kiszka
2012-03-21 23:17 ` [Qemu-devel] " Jan Kiszka
2012-03-21 23:17 ` [RFC][PATCH 1/2] kvm: Introduce basic MSI support in-kernel irqchips Jan Kiszka
2012-03-21 23:17   ` [Qemu-devel] " Jan Kiszka
2012-03-28 11:09   ` Avi Kivity
2012-03-28 11:09     ` [Qemu-devel] " Avi Kivity
2012-03-28 11:26     ` Michael S. Tsirkin
2012-03-28 11:26       ` [Qemu-devel] " Michael S. Tsirkin
2012-03-28 11:33     ` Jan Kiszka
2012-03-28 11:33       ` [Qemu-devel] " Jan Kiszka
2012-03-28 11:44       ` Avi Kivity
2012-03-28 11:44         ` [Qemu-devel] " Avi Kivity
2012-03-28 11:54         ` Jan Kiszka
2012-03-28 11:54           ` [Qemu-devel] " Jan Kiszka
2012-03-28 12:32           ` Avi Kivity
2012-03-28 12:32             ` [Qemu-devel] " Avi Kivity
2012-03-28 12:49             ` Jan Kiszka
2012-03-28 12:49               ` [Qemu-devel] " Jan Kiszka
2012-03-28 15:44         ` Michael S. Tsirkin
2012-03-28 15:44           ` [Qemu-devel] " Michael S. Tsirkin
2012-03-21 23:17 ` [RFC][PATCH 2/2] KVM: x86: Wire up MSI support for in-kernel irqchip Jan Kiszka
2012-03-21 23:17   ` [Qemu-devel] " Jan Kiszka
2012-03-28  7:13 ` [RFC][PATCH 0/2] uq/master: Basic MSI support for in-kernel irqchip mode Jan Kiszka
2012-03-28  7:13   ` [Qemu-devel] " Jan Kiszka
2012-03-28  9:45   ` Michael S. Tsirkin
2012-03-28  9:45     ` [Qemu-devel] " Michael S. Tsirkin
2012-03-28  9:50     ` Jan Kiszka
2012-03-28  9:50       ` [Qemu-devel] " Jan Kiszka
2012-03-28 10:47       ` Michael S. Tsirkin
2012-03-28 10:47         ` [Qemu-devel] " Michael S. Tsirkin
2012-03-28 11:07         ` Jan Kiszka
2012-03-28 11:07           ` [Qemu-devel] " Jan Kiszka
2012-03-28 11:31           ` Michael S. Tsirkin
2012-03-28 11:31             ` [Qemu-devel] " Michael S. Tsirkin
2012-03-28 11:36             ` Jan Kiszka
2012-03-28 11:36               ` [Qemu-devel] " Jan Kiszka
2012-03-28 15:43               ` Michael S. Tsirkin
2012-03-28 15:43                 ` [Qemu-devel] " Michael S. Tsirkin
2012-03-28 16:00                 ` Jan Kiszka [this message]
2012-03-28 16:00                   ` Jan Kiszka
2012-03-28 16:30                   ` Michael S. Tsirkin
2012-03-28 16:30                     ` [Qemu-devel] " Michael S. Tsirkin
2012-03-28 16:53                     ` Jan Kiszka
2012-03-28 16:53                       ` [Qemu-devel] " Jan Kiszka
2012-03-28 17:06                       ` Michael S. Tsirkin
2012-03-28 17:06                         ` [Qemu-devel] " Michael S. Tsirkin
2012-03-28 17:18                         ` Jan Kiszka
2012-03-28 17:18                           ` [Qemu-devel] " Jan Kiszka

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=4F733583.9060100@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.