From: Marcel Apfelbaum <marcel@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kwolf@redhat.com, alex.williamson@redhat.com, jiri@resnulli.us,
qemu-block@nongnu.org, jasowang@redhat.com,
Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org, keith.busch@intel.com,
Cao jin <caoj.fnst@cn.fujitsu.com>,
sfeldma@gmail.com, kraxel@redhat.com, dmitry@daynix.com,
pbonzini@redhat.com, jsnow@redhat.com,
Jan Kiszka <jan.kiszka@web.de>,
hare@suse.de
Subject: Re: [Qemu-devel] [PATCH RFC v2 1/2] Add param Error** to msi_init() & modify the callers
Date: Thu, 3 Mar 2016 13:19:09 +0200 [thread overview]
Message-ID: <56D81DAD.8040101@redhat.com> (raw)
In-Reply-To: <20160303123221-mutt-send-email-mst@redhat.com>
On 03/03/2016 12:45 PM, Michael S. Tsirkin wrote:
> On Thu, Mar 03, 2016 at 12:12:27PM +0200, Marcel Apfelbaum wrote:
>>>> +int msi_init(struct PCIDevice *dev, uint8_t offset, unsigned int nr_vectors,
>>>> + bool msi64bit, bool msi_per_vector_mask, Error **errp)
>>>> {
>>>> unsigned int vectors_order;
>>>> - uint16_t flags;
>>>> + uint16_t flags; /* Message Control register value */
>>>> uint8_t cap_size;
>>>> int config_offset;
>>>>
>>>> if (!msi_supported) {
>>>> + error_setg(errp, "MSI is not supported by interrupt controller");
>>>> return -ENOTSUP;
>>>
>>> First failure mode: board does not support MSI (-ENOTSUP).
>>>
>>> Question to the PCI guys: why is this even an error? A device with
>>> capability MSI should work just fine in such a board.
>>
>> Hi Markus,
>>
>> Adding Jan Kiszka, maybe he can help.
>>
>> That's a fair question. Is there any history for this decision?
>> The board not supporting MSI has nothing to do with the capability being there.
>> The HW should not change because the board doe not support it.
>>
>> The capability should be present but not active.
>
> Digging in git log will tell you why we have the msi_supported flag:
>
> commit 02eb84d0ec97f183ac23ee939403a139e8849b1d ("qemu/pci: MSI-X support functions")
>
> This is a safety measure to avoid breaking platforms which should support
> MSI-X but currently lack this in the interrupt controller emulation.
>
> in other words, on some platforms we must hide msi support from devices
> because otherwise guests will try to use it, and our emulation is
> incomplete.
OK, thanks. So the flag should be "msi_broken" or "msi_present_but_not_implemented" and not
"msi_supported" that leads (at least me) to the assumption that some platform *does not support msi*
rather than it supports it, but we don't emulate it.
>
> And the conclusion from that is that for msi_init to fail silently is
> at the moment the right thing to do.
But this is not the only thing we do, we are modifying the PCI devices. We could fail starting the VM
if a device supporting MSI is added on a platform with broken msi, but this will prevent us to use
assigned devices. Emulated devices should be created with a specific "msi=off" flag.
Thanks,
Marcel
>
> The only other reason for it to fail is pci config space corruption,
> this probably never happens in practice.
>
next prev parent reply other threads:[~2016-03-03 11:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-15 10:43 [Qemu-devel] [PATCH RFC v2 0/2] MSI/MSIX: fix to catch and report errors Cao jin
2015-12-15 10:43 ` [Qemu-devel] [PATCH RFC v2 1/2] Add param Error** to msi_init() & modify the callers Cao jin
2016-03-02 9:13 ` Markus Armbruster
2016-03-03 3:56 ` Cao jin
2016-03-03 10:12 ` Marcel Apfelbaum
2016-03-03 10:45 ` Michael S. Tsirkin
2016-03-03 11:19 ` Marcel Apfelbaum [this message]
2016-03-03 11:33 ` Michael S. Tsirkin
2016-03-03 15:03 ` Markus Armbruster
2016-03-03 18:33 ` Michael S. Tsirkin
2016-03-04 8:42 ` Markus Armbruster
2016-03-04 9:24 ` Michael S. Tsirkin
2016-03-04 12:57 ` Markus Armbruster
2016-03-04 13:10 ` Michael S. Tsirkin
2016-03-03 14:24 ` Markus Armbruster
2016-03-23 4:04 ` Cao jin
2016-03-23 8:12 ` Markus Armbruster
2016-03-23 9:23 ` Cao jin
2015-12-15 10:43 ` [Qemu-devel] [PATCH v2 RFC 2/2] Add param Error** to msix_init() " Cao jin
2015-12-17 8:02 ` [Qemu-devel] [PATCH RFC v2 0/2] MSI/MSIX: fix to catch and report errors Cao jin
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=56D81DAD.8040101@redhat.com \
--to=marcel@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=caoj.fnst@cn.fujitsu.com \
--cc=dmitry@daynix.com \
--cc=hare@suse.de \
--cc=jan.kiszka@web.de \
--cc=jasowang@redhat.com \
--cc=jiri@resnulli.us \
--cc=jsnow@redhat.com \
--cc=keith.busch@intel.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sfeldma@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 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).