qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/6] Misc PCI cleanups
Date: Tue, 09 Oct 2012 09:09:14 +0200	[thread overview]
Message-ID: <5073CD9A.3060702@siemens.com> (raw)
In-Reply-To: <1349730697.2759.211.camel@ul30vt.home>

On 2012-10-08 23:11, Alex Williamson wrote:
> On Mon, 2012-10-08 at 23:40 +0200, Michael S. Tsirkin wrote:
>> On Mon, Oct 08, 2012 at 01:27:33PM -0600, Alex Williamson wrote:
>>> On Mon, 2012-10-08 at 22:15 +0200, Michael S. Tsirkin wrote:
>>>> On Mon, Oct 08, 2012 at 09:58:32AM -0600, Alex Williamson wrote:
>>>>> Michael, Jan,
>>>>>
>>>>> Any comments on these?  I'd like to make the PCI changes before I update
>>>>> vfio-pci to make use of the new resampling irqfd in kvm.  We don't have
>>>>> anyone officially listed as maintainer of pci-assign since it's been
>>>>> moved to qemu.  I could include the pci-assign patches in my tree if you
>>>>> prefer.  Thanks,
>>>>>
>>>>> Alex
>>>>
>>>> Patches themselves look fine, but I'd like to
>>>> better understand why do we want the INTx fallback.
>>>> Isn't it easier to add intx routing support?
>>>
>>> vfio-pci can work with or without intx routing support.  Its presence is
>>> just one requirement to enable kvm accelerated intx support.  Regardless
>>> of whether it's easy or hard to implement intx routing in a given
>>> chipset, I currently can't probe for it and make useful decisions about
>>> whether or not to enable kvm support without potentially hitting an
>>> assert.  It's arguable how important intx acceleration is for specific
>>> applications, so while I'd like all chipsets to implement it, I don't
>>> know that it should be a gating factor to chipset integration.  Thanks,
>>>
>>> Alex
>>
>> Yes but there's nothing kvm specific in the routing API,
>> and IIRC it actually works fine without kvm.
> 
> Correct, but intx routing isn't very useful without kvm.

Right now: yes. Long-term: no. The concept in general is also required
for decoupling I/O paths lock-wise from our main thread. We need to
explore the IRQ path and cache it in order to avoid taking lots of locks
on each delivery, possibly even the BQL. But we will likely need
something smarter at that point, i.e. something PCI-independent.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

  parent reply	other threads:[~2012-10-09  7:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-02 19:21 [Qemu-devel] [PATCH 0/6] Misc PCI cleanups Alex Williamson
2012-10-02 19:21 ` [Qemu-devel] [PATCH 1/6] pci: Add INTx no-route option Alex Williamson
2012-10-02 19:21 ` [Qemu-devel] [PATCH 2/6] pci-assign: Add support for no-route Alex Williamson
2012-10-02 19:55   ` Anthony Liguori
2012-10-02 20:12     ` Alex Williamson
2012-10-03  9:52       ` Paolo Bonzini
2012-10-03 12:32         ` Anthony Liguori
2012-10-02 19:21 ` [Qemu-devel] [PATCH 3/6] pci: Helper function for testing if an INTx route changed Alex Williamson
2012-10-02 19:22 ` [Qemu-devel] [PATCH 4/6] pci-assign: Use pci_intx_route_changed() Alex Williamson
2012-10-02 19:22 ` [Qemu-devel] [PATCH 5/6] msi: Add msi_get_message() Alex Williamson
2012-10-02 19:22 ` [Qemu-devel] [PATCH 6/6] pci-assign: Use msi_get_message() Alex Williamson
2012-10-08 15:58 ` [Qemu-devel] [PATCH 0/6] Misc PCI cleanups Alex Williamson
2012-10-08 16:01   ` Jan Kiszka
2012-10-08 20:15   ` Michael S. Tsirkin
2012-10-08 19:27     ` Alex Williamson
2012-10-08 21:40       ` Michael S. Tsirkin
2012-10-08 21:11         ` Alex Williamson
2012-10-08 21:50           ` Michael S. Tsirkin
2012-10-08 22:09             ` Alex Williamson
2012-10-08 22:44               ` Michael S. Tsirkin
2012-10-08 23:54                 ` Alex Williamson
2012-10-11 14:11                   ` Michael S. Tsirkin
2012-10-09  7:09           ` Jan Kiszka [this message]
2012-10-10 19:31             ` Alex Williamson
2012-10-11 10:37               ` Michael S. Tsirkin
2012-10-11 13:38                 ` Alex Williamson
2012-10-11 13:49                   ` Michael S. Tsirkin
2012-10-11 14:10                     ` Alex Williamson

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=5073CD9A.3060702@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=alex.williamson@redhat.com \
    --cc=mst@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 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).