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. > (3) Consider a workaround for older guests anyway. The > scope of that workaround would depend on exactly which > guests are affected, which is presumably something we > figured out during step (1). 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. Therefore, if we want to stay compatible with such guests (which would be indeed old), we need an option which allows to turn off high MMIO region. Now the question is: what do we want as default on 32-bit virt? On 64 bits the default would be obviously "ON", what about 32 bits? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
