From: Jan Kiszka <jan.kiszka@web.de>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Isaku Yamahata <yamahata@valinux.co.jp>,
Gerd Hoffmann <kraxel@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH 4/6] msi: Invoke msi/msix_reset from PCI core
Date: Sun, 04 Dec 2011 15:35:38 +0100 [thread overview]
Message-ID: <4EDB853A.6050901@web.de> (raw)
In-Reply-To: <20111204142413.GA21238@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]
On 2011-12-04 15:24, Michael S. Tsirkin wrote:
> On Sun, Dec 04, 2011 at 02:22:12PM +0100, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> There is no point in pushing this burden to the devices, they may rather
>> forget to call them (like intel-hda and ahci ATM). Instead, reset
>> functions are now called from pci_device_reset and pci_bridge_reset.
>> They do nothing if the MSI/MSI-X is not in use.
>>
>> CC: Alexander Graf <agraf@suse.de>
>> CC: Gerd Hoffmann <kraxel@redhat.com>
>> CC: Isaku Yamahata <yamahata@valinux.co.jp>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>
> What makes me unhappy with this proposal is that msix_write_config, for
> example, becomes in fact an internal interface. So devices should be
> calling some functions like msix_init from msix.h, but not others like
> msix_write_config.
>
> It used to be simple: devices should call msix_.
> Now, how are devices to figure it out?
>
> E.g. the comment near msix_write_config says:
> /* Handle MSI-X capability config write. */
That should be aligned to msi_write_config's comment.
My goal is to reduce the number of calls devices have to do in order to
use MSI. We have quite a few correct examples by now, so it should not
be too hard to figure out what to do to use standard MSI[X] services.
Maybe a PCI skeleton device model would help further. Or up-to-date
documentation, thought that may be even harder. ;)
>
> This puts it at level 11 on Rusty's misuse scale:
> Read the documentation and you will get it wrong.
>
> So I tried writing a wapper, something like pci_capability.h, that would
> hide the detail and handle all capabilities seamlessly. Where I got
> stuck was migration though, format is ordered so we can't just move the
> fields around. So I decided to wait until we switch to an unordered
> format, then it'll become easy.
>
> Thoughts?
MSI-X save/restore is, well, unfortunate. Just like the whole PCI layer
in this regard. But I don't think that should block this particular step
as it frees device models from an unneeded burden.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2011-12-04 14:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-04 13:22 [Qemu-devel] [PATCH 0/6] msi: Small refactoring Jan Kiszka
2011-12-04 13:22 ` [Qemu-devel] [PATCH 1/6] msi: Guard msi/msix_write_config with msi_present Jan Kiszka
2011-12-04 13:22 ` [Qemu-devel] [PATCH 2/6] msi: Guard msi_reset " Jan Kiszka
2011-12-04 13:22 ` [Qemu-devel] [PATCH 3/6] msi: Use msi/msix_present more consistently Jan Kiszka
2011-12-04 13:22 ` [Qemu-devel] [PATCH 4/6] msi: Invoke msi/msix_reset from PCI core Jan Kiszka
2011-12-04 14:24 ` Michael S. Tsirkin
2011-12-04 14:35 ` Jan Kiszka [this message]
2011-12-04 14:48 ` Michael S. Tsirkin
2011-12-04 14:47 ` Jan Kiszka
2011-12-04 13:22 ` [Qemu-devel] [PATCH 5/6] msi: Invoke msi/msix_write_config " Jan Kiszka
2011-12-04 13:22 ` [Qemu-devel] [PATCH 6/6] msi: Generalize msix_supported to msi_supported 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=4EDB853A.6050901@web.de \
--to=jan.kiszka@web.de \
--cc=agraf@suse.de \
--cc=kraxel@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yamahata@valinux.co.jp \
/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.