| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAErSpo4aoHdSHp4+WWiSxDPmr5L_jSESm8ikdUxC_7tv99p1Bw@mail.gmail.com> Date: Fri, 26 Oct 2012 21:04:57 -0600 From: Bjorn Helgaas <bhelgaas@...gle.com> To: Cyberman Wu <cypher.w@...il.com> Cc: Chris Metcalf <cmetcalf@...era.com>, linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: PCIe IO space support on Tilera GX: Is there any one who can confirm my modification to fix it is OK? On Fri, Oct 26, 2012 at 7:39 PM, Cyberman Wu <cypher.w@...il.com> wrote: > On Sat, Oct 27, 2012 at 12:28 AM, Bjorn Helgaas <bhelgaas@...gle.com> wrote: >> On Fri, Oct 26, 2012 at 8:08 AM, Chris Metcalf <cmetcalf@...era.com> wrote: >> >>> Cyberman: it seems like your bias hack is working for you. But, as Bjorn >>> says, this sounds like a driver bug. What happens if you just revert your >>> changes, but then in mvsas.c change the "if (!res_start || !res_len)" to >>> just say "if (!res_len)"? That seems like the true error test. If that >>> works, you should submit that change to the community. >> >> I don't *think* that is going to be enough, even with the kernel that >> has some I/O space support, because both devices are assigned >> identical resources: >> >> pci 0000:01:00.0: BAR 2: assigned [io 0x0000-0x007f] >> pci 0001:01:00.0: BAR 2: assigned [io 0x0000-0x007f] >> >> The I/O space support that's there is broken because we think the same >> I/O range is available on both root buses, which is probably not the >> case: >> >> pci_bus 0000:00: resource 0 [io 0x0000-0xffffffff] >> pci_bus 0001:00: resource 0 [io 0x0000-0xffffffff] >> > That's the problem I want to confirm what I've changed is correct. I've split > the two RootComplex using separate I/O range, it seems works on our device, > but since I'm not very clear about Linux kernel, I want some some to check it. > For mvsas, I've already modified it some thing like Chris said when I began > using MDE-4.0.0 GA release. I bring it out to see if there have some ideas > about that issue. Some architectures do implement multiple I/O ranges. Typical HP parisc and ia64 boxes have a PCI host bridge for every slot, so each slot can be in a separate PCI domain, and each host bridge can support a separate 64KB I/O port space for its slot. In that case, the values in the struct resource will be different from the actual addresses that appear on the PCI buses. For example, you might have bridge A leading to bus 0000:00 with [io 0x0000-0xffff] and bridge B leading to bus 0001:00 with [io 0x10000-0x1ffff]. The I/O port addresses used by drivers don't overlap, and there's no ambiguity, but if you put an analyzer on bus 0001:00, you'd see port addresses in the 0x0000-0xffff range. If you moved the analyzer to bus 0000:00, you'd see the same 0x0000-0xffff range of port addresses. It's up to the architecture implementation of inb()/outb()/etc. to map an I/O resource address to a host bridge and a bus port address behind that bridge. The bottom line is that what you want to do seems possible and makes some sense. Of course, the diff you posted is useless for upstream Linux because it's all entangled with MDE and it reverts a lot of the recent Linux work. But what you want to do is possible in principle. It's up to you and Chris to figure out whether and how to rework the changes to add this functionality cleanly. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists