From: Jan Kiszka <jan.kiszka@siemens.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"avi@redhat.com" <avi@redhat.com>,
"shashidhar.patil@gmail.com" <shashidhar.patil@gmail.com>
Subject: Re: [PATCH v2 8/8] pci-assign: Update MSI-X config based on table writes
Date: Wed, 01 Feb 2012 15:13:33 +0100 [thread overview]
Message-ID: <4F29488D.5060401@siemens.com> (raw)
In-Reply-To: <1328104112.6937.190.camel@bling.home>
On 2012-02-01 14:48, Alex Williamson wrote:
> On Wed, 2012-02-01 at 09:22 +0200, Michael S. Tsirkin wrote:
>> On Tue, Jan 31, 2012 at 10:33:14PM -0700, Alex Williamson wrote:
>>> When a guest enables MSI-X in PCI configuration space we walk
>>> through the MSI-X vector table trying to guess what might get
>>> used. We have to guess because we don't do anything with
>>> writes to the vector table, so we look for clues ahead of time
>>> to pre-enable the vectors we think will be used. This means
>>> that instead of doing the sane thing and test the mask bit, we
>>> test whether the data field contains a non-zero value. It's
>>> amazing this works as well as it does.
>>>
>>> However, two key things missed by doing this is that we don't
>>> catch vector changes after enabling (ex. setting smp_affinity
>>> on an irq) and we don't support guests that don't touch the
>>> vector table prior to enabling the MSI-X capability (ex.
>>> freebsd). This patch fixes both of these problems.
>>>
>>> NB we're not actually masking vectors yet with this patch as
>>> it's unclear whether we really have the ability to do this
>>> without losing interrupts.
>>>
>>> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
>>
>> Overall I think this is better than what we have now.
>> One question though: would it make sense to use msix mask notifiers
>> instead of parsing msix tables on your own?
>
> Based on vfio, I think some minor changes would be necessary to the msix
> core to port to that infrastructure.
The core will require more changes as the current way of dealing with
KVM support for MSI[-X] is not upstreamable. This will affect the mask
notifier concept more or less as well.
> I don't think I'd want to use this
> code to push those changes since it likely won't get ported to qemu.git.
I'm pretty sure we will have pci assignment based on the KVM kernel
support upstream as well, simply because VFIO will take a while to show
up fully functional in distro kernels and because there is not that much
work required in addition to the core refactoring that we need to do anyway.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2012-02-01 14:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-01 5:32 [PATCH v2 0/8] pci-assign: better MSI-X table support Alex Williamson
2012-02-01 5:32 ` [PATCH v2 1/8] pci-assign: Fix warnings with DEBUG enabled Alex Williamson
2012-02-01 5:32 ` [PATCH v2 2/8] pci-assign: Update MSI-X MMIO to Memory API Alex Williamson
2012-02-01 5:32 ` [PATCH v2 3/8] pci-assign: Use struct for MSI-X table Alex Williamson
2012-02-01 5:32 ` [PATCH v2 4/8] pci-assign: Only calculate maximum MSI-X vector entries once Alex Williamson
2012-02-01 5:32 ` [PATCH v2 5/8] pci-assign: Proper initialization for MSI-X table Alex Williamson
2012-02-01 5:32 ` [PATCH v2 6/8] pci-assign: Allocate entries for all MSI-X vectors Alex Williamson
2012-02-01 5:33 ` [PATCH v2 7/8] pci-assign: Use MSIX_PAGE_SIZE Alex Williamson
2012-02-01 5:33 ` [PATCH v2 8/8] pci-assign: Update MSI-X config based on table writes Alex Williamson
2012-02-01 7:22 ` Michael S. Tsirkin
2012-02-01 13:48 ` Alex Williamson
2012-02-01 14:13 ` Jan Kiszka [this message]
2012-02-01 15:13 ` Michael S. Tsirkin
2012-02-01 7:25 ` Michael S. Tsirkin
2012-02-01 13:51 ` Alex Williamson
2012-02-07 20:04 ` [PATCH v2 0/8] pci-assign: better MSI-X table support Marcelo Tosatti
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=4F29488D.5060401@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=alex.williamson@redhat.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=shashidhar.patil@gmail.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 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.