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>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Cc: "alistair@popple.id.au" <alistair@popple.id.au>,
"nikunj@linux.vnet.ibm.com" <nikunj@linux.vnet.ibm.com>,
"zhong@linux.vnet.ibm.com" <zhong@linux.vnet.ibm.com>,
"eric.auger@linaro.org" <eric.auger@linaro.org>,
"aik@ozlabs.ru" <aik@ozlabs.ru>,
"joro@8bytes.org" <joro@8bytes.org>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"gwshan@linux.vnet.ibm.com" <gwshan@linux.vnet.ibm.com>,
"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 v6 06/10] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag
Date: Tue, 19 Apr 2016 19:13:54 +0800 [thread overview]
Message-ID: <571612F2.1080502@linux.vnet.ibm.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F4A45A8@AcuExch.aculab.com>
On 2016/4/18 19:30, David Laight wrote:
> From: Yongji Xie
>> Sent: 18 April 2016 11:59
>> We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
>> which indicates all devices on the bus are protected by the
>> hardware which supports IRQ remapping(intel naming).
>>
>> This flag will be used to know whether it's safe to expose
>> MSI-X tables of PCI BARs to userspace. Because the capability
>> of IRQ remapping can guarantee the PCI device cannot trigger
>> MSIs that correspond to interrupt IDs of other devices.
> I'm worried that this entire series is going to break drivers
> for existing hardware.
>
> I understand some of the reasoning for 'vm pass through' configurations,
> but there will be PCIe devices out there that have the MSI-X tables
> in the same BAR as other device registers.
> If you are lucky nothing else is in the same 4k area, but I wouldn't
> assume it.
Thanks for your comments. But I didn't get your point here.
Why will exposing MSI-X table to userspace break the driver
for hardware which have the MSI-X tables in the same BAR as
other device registers? Could you give me more details?
The reason why we want to mmap MSI-X table is that there
may be some other critical device registers in the same page
as the MSI-X table. We prefer to handle the mmio access to
these registers in guest rather than in QEMU. So we would
like to see there is something else in the same 4k/64k area.
> In any case, if the hardware can't police the card's master transfers
> there is nothing to stop a different bus master block on the card
> from raising MSI-X interrupts - they are just a PCIe write.
> So all you are doing is raising the bar slightly and giving a very false
> sense of security.
Do you mean we can request a DMA to the target address
area that raises MSI-X interrupts? But for PPC64 with IODA
bridge, this invalid PCIe write will be prevented on PHB before
raising MSI-X interrupt. And I think the capability of interrupt
remapping or ITS can also do the same thing. If hardware didn't
support this, we would not expose MSI-X table in my patch.
Thanks,
Yongji
prev parent reply other threads:[~2016-04-19 11:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-18 10:58 [RFC v6 06/10] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag Yongji Xie
2016-04-18 10:58 ` [RFC v6 07/10] iommu: Set PCI_BUS_FLAGS_MSI_REMAP if IOMMU have capability of IRQ remapping Yongji Xie
2016-04-18 11:30 ` [RFC v6 06/10] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag David Laight
2016-04-19 11:13 ` Yongji Xie [this message]
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=571612F2.1080502@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=alistair@popple.id.au \
--cc=bhelgaas@google.com \
--cc=eric.auger@linaro.org \
--cc=gwshan@linux.vnet.ibm.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--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=will.deacon@arm.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 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).