From: Yongji Xie <xyjxie@linux.vnet.ibm.com>
To: David Laight <David.Laight@ACULAB.COM>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Cc: "nikunj@linux.vnet.ibm.com" <nikunj@linux.vnet.ibm.com>,
"zhong@linux.vnet.ibm.com" <zhong@linux.vnet.ibm.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"aik@ozlabs.ru" <aik@ozlabs.ru>,
"warrier@linux.vnet.ibm.com" <warrier@linux.vnet.ibm.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"paulus@samba.org" <paulus@samba.org>,
"bhelgaas@google.com" <bhelgaas@google.com>
Subject: Re: [RFC PATCH v3 3/5] PCI: Add host bridge attribute to indicate filtering of MSIs is supported
Date: Wed, 20 Jan 2016 17:41:10 +0800 [thread overview]
Message-ID: <569F5636.30701@linux.vnet.ibm.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CCC6833@AcuExch.aculab.com>
On 2016/1/16 1:24, David Laight wrote:
> From: Yongji Xie
>> Sent: 15 January 2016 07:06
>>
>> MSI-X tables are not allowed to be mmapped in vfio-pci
>> driver in case that user get to touch this directly.
>> This will cause some performance issues when when PCI
>> adapters have critical registers in the same page as
>> the MSI-X table.
> ...
> If the driver wants to generate an incorrect MSI-X interrupt
> it can do so by requesting the device do a normal memory transfer
> to the target address area that raises MSI-X interrupts.
IOMMUs supporting interrupt remapping can prevent this case.
> So disabling writes to the MSI-X table (and pending bit array)
> areas only raises the bar very slightly.
> A device may also give the driver write access to the MSI-X
> table through other addresses.
>
> This seems to make disallowing the mapping of the MSI-X table
> rather pointless.
If we allow the mapping of the MSI-X table, it seems the guest
kernels of some architectures can write invalid data to MSI-X table
when device drivers initialize MSI-X interrupts.
Regards,
Yongji Xie
> I've also dumped out the MSI-X table (during development) to
> check that the values are being written there correctly.
>
> David
>
next prev parent reply other threads:[~2016-01-20 9:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-15 7:06 [RFC PATCH v3 0/5] vfio-pci: Allow to mmap sub-page MMIO BARs and MSI-X table on PPC64 platform Yongji Xie
2016-01-15 7:06 ` [RFC PATCH v3 1/5] PCI: Add support for enforcing all MMIO BARs to be page aligned Yongji Xie
2016-01-28 22:46 ` Alex Williamson
2016-01-29 10:37 ` Yongji Xie
2016-01-29 19:01 ` Alex Williamson
2016-02-01 8:50 ` Yongji Xie
2016-02-01 8:50 ` Yongji Xie
2016-01-15 7:06 ` [RFC PATCH v3 2/5] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive Yongji Xie
2016-01-15 7:06 ` [RFC PATCH v3 3/5] PCI: Add host bridge attribute to indicate filtering of MSIs is supported Yongji Xie
2016-01-15 17:24 ` David Laight
2016-01-15 17:24 ` David Laight
2016-01-20 9:41 ` Yongji Xie [this message]
2016-01-28 22:46 ` Alex Williamson
2016-01-29 10:40 ` Yongji Xie
2016-01-29 19:05 ` Alex Williamson
2016-02-01 9:13 ` Yongji Xie
2016-02-01 9:13 ` Yongji Xie
2016-01-15 7:06 ` [RFC PATCH v3 4/5] powerpc/powernv/pci-ioda: Enable msi_filtered bit for any IODA host bridge Yongji Xie
2016-01-15 7:06 ` [RFC PATCH v3 5/5] vfio-pci: Allow to mmap MSI-X table if host bridge supports filtering of MSIs Yongji Xie
2016-01-28 22:46 ` Alex Williamson
2016-01-29 10:42 ` Yongji Xie
2016-01-28 10:01 ` [RFC PATCH v3 0/5] vfio-pci: Allow to mmap sub-page MMIO BARs and MSI-X table on PPC64 platform Yongji Xie
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=569F5636.30701@linux.vnet.ibm.com \
--to=xyjxie@linux.vnet.ibm.com \
--cc=David.Laight@ACULAB.COM \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=corbet@lwn.net \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=nikunj@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=warrier@linux.vnet.ibm.com \
--cc=zhong@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.