Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1382405
| From | Yongji Xie <xyjxie@linux.vnet.ibm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC v6 06/10] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag |
| Date | 2016-04-19 13:20 +0200 |
| Message-ID | <rpBRg-615-27@gated-at.bofh.it> (permalink) |
| References | <rpfe3-4x7-41@gated-at.bofh.it> <rpfH4-4Ou-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[RFC v6 06/10] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag Yongji Xie <xyjxie@linux.vnet.ibm.com> - 2016-04-18 13:10 +0200
RE: [RFC v6 06/10] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag David Laight <David.Laight@ACULAB.COM> - 2016-04-18 13:40 +0200
Re: [RFC v6 06/10] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag Yongji Xie <xyjxie@linux.vnet.ibm.com> - 2016-04-19 13:20 +0200
csiph-web