Re: [Qemu-devel] [PATCH v3] hw/arm/virt: Add high MMIO PCI region

[Peter Maydell]

On 3 August 2015 at 08:03, Pavel Fedin <address@hidden> 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