From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Laight Subject: Re: [PATCH 1/3] PCI/MSI: Add pci_enable_msi_partial() Date: Tue, 8 Jul 2014 08:33:17 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1726E211__49085.1242714145$1404808579$gmane$org@AcuExch.aculab.com> References: <4fef62a2e647a7c38e9f2a1ea4244b3506a85e2b.1402405331.git.agordeev@redhat.com> <20140702202201.GA28852@google.com> <063D6719AE5E284EB5DD2968C1650D6D1726BF4E@AcuExch.aculab.com> <20140704085816.GB12247@dhcp-26-207.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1X4QrO-0008PM-NR for xen-devel@lists.xenproject.org; Tue, 08 Jul 2014 08:34:46 +0000 Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 21390-03 for ; Tue, 8 Jul 2014 09:34:44 +0100 (BST) In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: 'Bjorn Helgaas' , Alexander Gordeev Cc: "linux-mips@linux-mips.org" , "linux-s390@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-pci@vger.kernel.org" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "linux-ide@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "xen-devel@lists.xenproject.org" , "linuxppc-dev@lists.ozlabs.org" List-Id: xen-devel@lists.xenproject.org From: Bjorn Helgaas ... > >> Even if you do that, you ought to write valid interrupt information > >> into the 4th slot (maybe replicating one of the earlier interrupts). > >> Then, if the device does raise the 'unexpected' interrupt you don't > >> get a write to a random kernel location. > > > > I might be missing something, but we are talking of MSI address space > > here, aren't we? I am not getting how we could end up with a 'write' > > to a random kernel location when a unclaimed MSI vector sent. We could > > only expect a spurious interrupt at worst, which is handled and reported. > > Yes, that's how I understand it. With MSI, the OS specifies the a > single Message Address, e.g., a LAPIC address, and a single Message > Data value, e.g., a vector number that will be written to the LAPIC. > The device is permitted to modify some low-order bits of the Message > Data to send one of several vector numbers (the MME value tells the > device how many bits it can modify). > > Bottom line, I think a spurious interrupt is the failure we'd expect > if a device used more vectors than the OS expects it to. So you need to tell the device where to write in order to raise the 'spurious interrupt'. David