From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: kvm@vger.kernel.org, Alexey Kardashevskiy <aik@ozlabs.ru>,
Jan Kiszka <jan.kiszka@siemens.com>,
qemu-devel@nongnu.org, Alex Graf <agraf@suse.de>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API
Date: Tue, 05 Jun 2012 11:39:33 +1000 [thread overview]
Message-ID: <1338860373.7150.95.camel@pasglop> (raw)
In-Reply-To: <1337870494.4714.1.camel@ul30vt>
> Yep, that's what I'd suggest as well, add a blacklist to
> pci_intx_mask_supported() so this device returns false and we require an
> exclusive interrupt for it. Thanks,
BTW, we should consider supporting an MSI-only option for guests as
well:
LSIs are a problem for virtualization, especially when we start
having things like expander racks with slots behind bridges etc, and
in some case it's better to support an MSI only setup rather than
not support the virtualizing the devices at all (or at least in
different partitions).
However, to do that, we either need to ensure the device can't be
coerced by SW to still assert the LSI and cause trouble. This can be
dealt with two ways I have in mind:
- If we don't use any of those 4 interrupts lines at all (ie, we use no
LSI on the host bridge and they aren't shared with another bridge
etc...), we can just mask them out in the main PIC. On Power there's no
sharing between interrupt sources from different host bridges so that
would work for us
- If the intermediary P2P bridge has a feature to block incoming LSIs
from children (I've heard that exists, is that standard ? I haven't
looked in the latest specs)
There's a third one:
- If you trust the device own mask bit
... But this is fishy since many devices -will- have some kind of
backdoor via MMIO to bypass (or alter) the config space setting. In some
cases the driver can even completely replace the firmware inside the
device and do pretty much whatever it wants :-)
The main thing is how do we "represent" both in term of interface to
qemu and qemu -> kernel interface wanting such a "no LSI" setup... not
sure about that one.
Cheers,
Ben.
next prev parent reply other threads:[~2012-06-05 1:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-24 7:44 [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API Alexey Kardashevskiy
2012-05-24 12:02 ` Jan Kiszka
2012-05-24 14:41 ` Alex Williamson
2012-05-25 1:06 ` Alexey Kardashevskiy
2012-06-05 1:39 ` Benjamin Herrenschmidt [this message]
2012-06-05 1:44 ` Alexander Graf
2012-06-05 2:56 ` Benjamin Herrenschmidt
2012-05-25 1:18 ` Alexey Kardashevskiy
2012-05-25 2:29 ` Jan Kiszka
2012-05-25 2:47 ` Alexey Kardashevskiy
2012-05-25 10:43 ` Jan Kiszka
2012-05-25 11:26 ` Alexey Kardashevskiy
2012-05-25 11:31 ` Jan Kiszka
2012-06-05 1:39 ` Benjamin Herrenschmidt
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=1338860373.7150.95.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--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).