On 3 August 2015 at 08:03, Pavel Fedin <p.fe...@samsung.com> wrote: > Hi! I have done an additional study... > >> (1) We should confirm whether this really is a guest kernel >> bug (as opposed to the device tree QEMU emits not being >> in spec) >> (2) If it is a kernel bug, submit a patch to fix it > > It is a bug, but not major bug. The bug is only that the kernel > tries to map the device anyway, despite it takes wrong, truncated > physical addresses. But, if we fix it, then the only option for > the kernel is not to try to use this device at all. Because, in > general case, this would mean that the device is outside of usable > address space, and we cannot access it, therefore cannot drive it > properly. > Therefore, the non-LPAE-enabled kernel will not be able to use PCI > controller with high MMIO anyway.
Right, you can't use a device that's not in the accessible range for you. But that's always going to be the case -- a non-LPAE kernel just can't get at anything outside the 32-bit physical address window. If you want a high-MMIO window to actually work you're going to need LPAE enabled. 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.) > 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? -- PMM
