[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe b
From: |
Auger Eric |
Subject: |
Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses |
Date: |
Thu, 24 May 2018 16:09:08 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
Hi Laszlo,
On 05/24/2018 03:59 PM, Laszlo Ersek wrote:
> On 05/24/18 15:07, Peter Maydell wrote:
>> On 24 May 2018 at 13:59, Laszlo Ersek <address@hidden> wrote:
>>> On 05/24/18 11:11, Peter Maydell wrote:
>>>> Won't it also break a guest which is just Linux loaded not via
>>>> firmware which is an aarch32 kernel without LPAE support?
>>>
>>> Does such a thing exist? (I honestly have no clue.)
>>
>> Yes, it does; LPAE isn't a mandatory kernel config option.
>> This is why we have the machine 'highmem' option, so that
>> we can run on those kernels by not putting anything above
>> the 4G boundary. Looking back at the history on that, we
>> opted at the time for "default to highmem on, and if you're
>> running an non-lpae kernel you need to turn it off manually".
>
> Ah, OK, I didn't know that.
>
>> So we can handle those kernels by just not putting ECAM
>> above 4G if highmem is false.
>
> The problem is we can have a combination of 32-bit UEFI firmware (which
> certainly lacks LPAE) and a 32-bit kernel which supports LPAE.
Is it what happens with the FW you provided to me? There is no LPAE in it?
> Previously, you wouldn't specify highmem=off, and things would just work
> -- the firmware would simply ignore the >=4GB MMIO apertur e, and use the
> 32-bit MMIO aperture only (and use the sole 32-bit ECAM). The kernel
> could then use both low and high MMIO apertures, however (I gather?).
>
> The difference with "high ECAM" is that it is *moved* (not *added*), so
> the 32-bit firmware is left with nothing for config space access.
Yes it is not possible to declare several disjoint ECAM spaces for a
single segment I think, hence the move.
For
> booting the same combination as above, you are suddenly forced to add
> highmem=off, just to keep the ECAM low -- and that, while it keeps the
> firmware happy, prevents the LPAE-capable kernel from using the high
> MMIO aperture.
>
> So I think "highmem_ecam" should be computed like this:
>
> highmem_ecam = highmem_ecam_machtype_default &&
> highmem &&
> (!firmware_loaded || aarch64);
Looks sensible to me
Thanks
Eric
>
> Thanks,
> Laszlo
>
- [Qemu-arm] [RFC 1/2] hw/arm/virt: Add a new 256MB ECAM region, (continued)
- [Qemu-arm] [RFC 1/2] hw/arm/virt: Add a new 256MB ECAM region, Eric Auger, 2018/05/23
- Re: [Qemu-arm] [RFC 0/2] ARM virt: Support up to 256 PCIe buses, Laszlo Ersek, 2018/05/23
- Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses, Auger Eric, 2018/05/23
- Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses, Laszlo Ersek, 2018/05/23
- Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses, Auger Eric, 2018/05/23
- Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses, Peter Maydell, 2018/05/24
- Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses, Laszlo Ersek, 2018/05/24
- Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses, Peter Maydell, 2018/05/24
- Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses, Auger Eric, 2018/05/24
- Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses, Laszlo Ersek, 2018/05/24
- Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses,
Auger Eric <=
- Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses, Laszlo Ersek, 2018/05/24
- Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses, Ard Biesheuvel, 2018/05/24
- Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses, Laszlo Ersek, 2018/05/24
- Re: [Qemu-arm] [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses, Auger Eric, 2018/05/24