From: Auger Eric <eric.auger@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>,
Laszlo Ersek <lersek@redhat.com>
Cc: Eric Auger <eric.auger.pro@gmail.com>,
QEMU Developers <qemu-devel@nongnu.org>,
qemu-arm <qemu-arm@nongnu.org>, Wei Huang <wei@redhat.com>,
Andrew Jones <drjones@redhat.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Shannon Zhao <zhaoshenglong@huawei.com>
Subject: Re: [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses
Date: Thu, 24 May 2018 15:10:41 +0200 [thread overview]
Message-ID: <8a2e04d2-68a8-5ea6-b0a6-6df4b6c029e2@redhat.com> (raw)
In-Reply-To: <CAFEAcA-hobu_=VKhYQ+UZ1WX_JFfwCarkPKQhiBtXc3fre57rg@mail.gmail.com>
Hi Peter, Laszlo,
On 05/24/2018 03:07 PM, Peter Maydell wrote:
> On 24 May 2018 at 13:59, Laszlo Ersek <lersek@redhat.com> 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".
> So we can handle those kernels by just not putting ECAM
> above 4G if highmem is false.
Actually that's what my series does. If highmem=off then we use the
legacy ECAM.
Thanks
Eric
>
> thanks
> -- PMM
>
next prev parent reply other threads:[~2018-05-24 13:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-23 16:03 [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses Eric Auger
2018-05-23 16:03 ` [Qemu-devel] [RFC 1/2] hw/arm/virt: Add a new 256MB ECAM region Eric Auger
2018-05-23 16:03 ` [Qemu-devel] [RFC 2/2] hw/arm/virt: Add virt-3.0 machine type Eric Auger
2018-05-23 17:45 ` [Qemu-devel] [RFC 0/2] ARM virt: Support up to 256 PCIe buses Laszlo Ersek
2018-05-23 20:40 ` Auger Eric
2018-05-23 20:52 ` Laszlo Ersek
2018-05-23 20:55 ` Auger Eric
2018-05-24 9:11 ` Peter Maydell
2018-05-24 12:59 ` Laszlo Ersek
2018-05-24 13:07 ` Peter Maydell
2018-05-24 13:10 ` Auger Eric [this message]
2018-05-24 13:59 ` Laszlo Ersek
2018-05-24 14:09 ` Auger Eric
2018-05-24 16:58 ` Laszlo Ersek
2018-05-24 14:14 ` Ard Biesheuvel
2018-05-24 17:20 ` Laszlo Ersek
2018-05-24 19:26 ` Auger Eric
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8a2e04d2-68a8-5ea6-b0a6-6df4b6c029e2@redhat.com \
--to=eric.auger@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=drjones@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=lersek@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wei@redhat.com \
--cc=zhaoshenglong@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).