Hi! > What I thought you meant was that a non-LPAE kernel didn't > work at all if we told it about the high-MMIO window (which > would mean we'd need to *not* put that in the dtb if we > wanted to avoid breaking non-LPAE guests that didn't care > about the other window.)
Current generic PCI driver is not so smart. It simply tries to map all resources using devm_request_resource() in a loop. If a single call fails, the driver thinks that it cannot work and fails. It does not try to ignore inaccessible regions. > > The behavior which i explained above causes boot problems if our > > configuration assumes that we boot off emulated PCI device. Because > > PCI controller becomes unusable. > > ...which is what you're saying here. > > Which is it? I don't understand this last question... Ok, from scratch: imagine that we already have a qemu installation running non-LPAE 32-bit guest. This guest is configured to have PCI bus and SCSI drive on this bus, and boots off it. Now, if we implement a high MMIO window in qemu, which is unconditionally enabled, after qemu upgrade this guest will break, because its pre-existing kernel cannot work around the inaccessible PCI region. In order to keep this guest working, we need a possibility to disable the new MMIO region in qemu. At least to omit it from the device tree. Is this clear enough now ? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
