From: Sean Christopherson <seanjc@google.com>
To: Bharata B Rao <bharata@amd.com>
Cc: Borislav Petkov <bp@alien8.de>,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, x86@kernel.org, dave.hansen@linux.intel.com,
nikunj@amd.com, hpa@zytor.com, Abraham.Shaju@amd.com
Subject: Re: [RFC FIX PATCH] x86/e820: Stop kernel boot when RAM resource reservation fails
Date: Tue, 19 Jul 2022 17:12:38 +0000 [thread overview]
Message-ID: <YtbmBldwL+h2X+V4@google.com> (raw)
In-Reply-To: <24ccd22f-6708-3265-4012-66f01108ff22@amd.com>
On Tue, Jul 19, 2022, Bharata B Rao wrote:
> On 7/18/2022 8:37 PM, Borislav Petkov wrote:
> >
> > I betcha you can generate a lot of "kernel bugs" with weird qemu
> > options. If it is not a real use case, nobody cares.
>
> I see that we will hit this problem by default when starting
> a guest with 1T or more memory using QEMU.
That a user can create a bad configuration using QEMU's default MAXPHYADDR doesn't
change the fact that adding memory beyond MAXPHYADDR is firmly a configuration bug.
> > And even if it were a real use case, panicking the machine is not the
> > right fix.
>
> I couldn't see a clean exit/recovery option in setup_arch()->e820__reserve_resources()
> where this happens. Any suggestions?
WARN or pr_err/warn() and move on, or just do nothing. Adding code to try and
gracefully handle an architecturally impossible configuration is a waste of time
and effort. Like Boris said, there's practically a limitless number of bad setups
QEMU can create, this one just happens to be easier to create than others due to
shortcomings in QEMU.
next prev parent reply other threads:[~2022-07-19 17:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-18 8:58 [RFC FIX PATCH] x86/e820: Stop kernel boot when RAM resource reservation fails Bharata B Rao
2022-07-18 10:42 ` Boris Petkov
2022-07-18 14:54 ` Bharata B Rao
2022-07-18 15:07 ` Borislav Petkov
2022-07-19 4:15 ` Bharata B Rao
2022-07-19 17:12 ` Sean Christopherson [this message]
2022-08-04 9:46 ` Ingo Molnar
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=YtbmBldwL+h2X+V4@google.com \
--to=seanjc@google.com \
--cc=Abraham.Shaju@amd.com \
--cc=bharata@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.