On Tue, Feb 18, 2014 at 06:59:47PM +0000, Jason Gunthorpe wrote: > On Tue, Feb 18, 2014 at 06:44:20PM +0000, Will Deacon wrote: > > On Tue, Feb 18, 2014 at 06:21:42PM +0000, Jason Gunthorpe wrote: > > > On Tue, Feb 18, 2014 at 12:20:43PM +0000, Will Deacon wrote: > > > > + > > > > + // BUS_ADDRESS(3) CPU_PHYSICAL(2) SIZE(2) > > > > + ranges = <0x1000000 0x0 0x00000000 0x0 0x00000000 0x0 0x00010000>, > > > ^^^^^^^^^^^^^^ > > > > > > This probably shouldn't be 0 in the example, nor in your kvm tool > > > output. For example purposes any value will do. > > > > Hmm, so kvmtool actually provides a PC ioport at 0x0, which is handy since > > there's an 8250 down there. That means we have: > > > > 0x0 - 0x6200 : Weird PC stuff > > 0x6200 - 0x10000 : PCI IO space > > > > Should I just change everything to be offset by 0x6200? > > Just to be clear, kvm has reserved the first 64k of physical address > space for this IO window? The 0 is fine then, but it isn't typical of > real hardware. Yup, that's spot on. > Regarding the 0x6200.. There are two conflicting issues there :( > - You really don't want to let the PCI core assign resources to that > range, it probably won't work. Right, with kvmtool we don't support resource assignment (the BARs are fixed) so everything is PCI_PROBE_ONLY. > - You probably need that range mapped into the ARM IO window, and the > PCI driver is the thing doing that > > The PCI core already has a black out for low IO ports, I think it > already covers the usual PC suspects so you are probably fine with > what you have for KVM. Great, so I'll just update the example then. Thanks! Will -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
