From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLtZV-0002Im-Je for qemu-devel@nongnu.org; Thu, 24 May 2018 12:58:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fLtZU-0005CF-Pm for qemu-devel@nongnu.org; Thu, 24 May 2018 12:58:37 -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: <694034a3-9d4c-3e7e-759d-6fd8f8cfd9c8@redhat.com> Date: Thu, 24 May 2018 18:58:22 +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: Auger Eric , Peter Maydell Cc: Wei Huang , Andrew Jones , Ard Biesheuvel , QEMU Developers , qemu-arm , Shannon Zhao , Eric Auger On 05/24/18 16:09, Auger Eric wrote: > 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 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? That's the case, to my knowledge. Thanks Laszlo