Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755955AbbLQKJc (ORCPT ); Thu, 17 Dec 2015 05:09:32 -0500 Received: from smtp-out6.electric.net ([192.162.217.183]:50242 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755332AbbLQKJ3 (ORCPT ); Thu, 17 Dec 2015 05:09:29 -0500 From: David Laight To: "'Alex Williamson'" , Yongji Xie , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" CC: "nikunj@linux.vnet.ibm.com" , "zhong@linux.vnet.ibm.com" , "aik@ozlabs.ru" , "paulus@samba.org" , "warrier@linux.vnet.ibm.com" Subject: RE: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported Thread-Topic: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported Thread-Index: AQHROD40DC0ohk0fwkq5PmT6EqV+OZ7O8Msg Date: Thu, 17 Dec 2015 10:08:04 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CBEF1BC@AcuExch.aculab.com> References: <1449823994-3356-1-git-send-email-xyjxie@linux.vnet.ibm.com> <1449823994-3356-4-git-send-email-xyjxie@linux.vnet.ibm.com> <1450296869.2674.62.camel@redhat.com> In-Reply-To: <1450296869.2674.62.camel@redhat.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tBHA9cu0015211 Content-Length: 1638 Lines: 34 > The MSI-X table is paravirtualized on vfio in general and interrupt > remapping theoretically protects against errant interrupts, so why is > this PPC64 specific? We have the same safeguards on x86 if we want to > decide they're sufficient. Offhand, the only way I can think that a > device can touch the MSI-X table is via backdoors or p2p DMA with > another device. Is this all related to the statements in the PCI(e) spec that the MSI-X table and Pending bit array should in their own BARs? (ISTR it even suggests a BAR each.) Since the MSI-X table exists in device memory/registers there is nothing to stop the device modifying the table contents (or even ignoring the contents and writing address+data pairs that are known to reference the CPUs MSI-X interrupt generation logic). We've an fpga based PCIe slave that has some additional PCIe slaves (associated with the interrupt generation logic) that are currently next to the PBA (which is 8k from the MSI-X table). If we can't map the PBA we can't actually raise any interrupts. The same would be true if page size is 64k and mapping the MSI-X table banned. Do we need to change our PCIe slave address map so we don't need to access anything in the same page (which might be 64k were we to target large ppc - which we don't at the moment) as both the MSI-X table and the PBA? I'd also note that being able to read the MSI-X table is a useful diagnostic that the relevant interrupts are enabled properly. David ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?