From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56527) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLqmD-0005Ea-F6 for qemu-devel@nongnu.org; Thu, 24 May 2018 09:59:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fLqmC-00060M-Kj for qemu-devel@nongnu.org; Thu, 24 May 2018 09:59:33 -0400 References: <1527091418-11874-1-git-send-email-eric.auger@redhat.com> <22c4e504-a7b4-e6dd-b2cc-618d306b6f0c@redhat.com> <550464ac-5155-6311-d0f7-92c7c0813f82@redhat.com> From: Laszlo Ersek Message-ID: Date: Thu, 24 May 2018 15:59:17 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Auger Eric , Eric Auger , QEMU Developers , qemu-arm , Wei Huang , Andrew Jones , Ard Biesheuvel , Shannon Zhao On 05/24/18 15:07, Peter Maydell wrote: > On 24 May 2018 at 13:59, Laszlo Ersek 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. Previously, you wouldn't specify highmem=off, and things would just work -- the firmware would simply ignore the >=4GB MMIO aperture, 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. 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); Thanks, Laszlo