From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbikO-0003SV-Cb for qemu-devel@nongnu.org; Mon, 04 Jun 2012 21:39:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbikM-0003BN-LH for qemu-devel@nongnu.org; Mon, 04 Jun 2012 21:39:47 -0400 Received: from gate.crashing.org ([63.228.1.57]:41778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbikM-0003BB-Ce for qemu-devel@nongnu.org; Mon, 04 Jun 2012 21:39:46 -0400 Message-ID: <1338860373.7150.95.camel@pasglop> From: Benjamin Herrenschmidt Date: Tue, 05 Jun 2012 11:39:33 +1000 In-Reply-To: <1337870494.4714.1.camel@ul30vt> References: <4FBDE6D6.80700@ozlabs.ru> <4FBE2349.6040800@siemens.com> <1337870494.4714.1.camel@ul30vt> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: kvm@vger.kernel.org, Alexey Kardashevskiy , Jan Kiszka , qemu-devel@nongnu.org, Alex Graf , David Gibson > 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.