From: Dave Hansen <dave.hansen@intel.com>
To: Saurabh Sengar <ssengar@linux.microsoft.com>,
kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
mikelley@microsoft.com, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, hpa@zytor.com
Subject: Re: [PATCH v2] x86/hyperv: add noop functions to x86_init mpparse functions
Date: Tue, 13 Jun 2023 10:33:07 -0700 [thread overview]
Message-ID: <23749756-022a-5574-af4d-a4a03d9542e1@intel.com> (raw)
In-Reply-To: <1686640391-13001-1-git-send-email-ssengar@linux.microsoft.com>
On 6/13/23 00:13, Saurabh Sengar wrote:
> In certain configurations, VTL0 and VTL2 can share the same VM
> partition and hence share the same memory address space. In such
> systems VTL2 has visibility of all of the VTL0 memory space.
FWIW, this is pretty much gibberish to me. The way I suggest avoiding
producing gibberish is avoiding acronyms:
Hyper-V can run VMs at different privilege "levels". Sometimes,
it chooses to run two different VMs at different levels but
they share some of their address space. This <insert reason
that someone might want to do this>.
That's not gibberish.
> When CONFIG_X86_MPPARSE is enabled for VTL2, the kernel performs
> a scan of low memory to search for MP tables. However, in systems
> where VTL0 controls the low memory and may contain valid tables
> specific to VTL0, this scanning process can lead to confusion
> within the VTL2 kernel.
What is the end-user-visible effect of this "confusion"? A crash? A
warning? An error message? What is the impact on end users?
This information will help the maintainers decide how to disposition
your patch. Should we send it upstream immediately because it's
impacting millions of users? Or can we do it in a bit more leisurely
fashion because nobody cares?
> In !ACPI system, there is no way to disable CONFIG_X86_MPPARSE
> hence add the noop function instead.
This makes zero sense to me.
Like I told you before, we don't compile things out just because they
don't work on one weirdo system. If we did that, we'd have a billion
incompatible x86 kernel images that can't boot across systems.
next prev parent reply other threads:[~2023-06-13 17:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 7:13 [PATCH v2] x86/hyperv: add noop functions to x86_init mpparse functions Saurabh Sengar
2023-06-13 17:33 ` Dave Hansen [this message]
2023-06-14 4:05 ` [EXTERNAL] " Saurabh Singh Sengar
2023-06-20 10:09 ` Saurabh Singh Sengar
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=23749756-022a-5574-af4d-a4a03d9542e1@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikelley@microsoft.com \
--cc=mingo@redhat.com \
--cc=ssengar@linux.microsoft.com \
--cc=tglx@linutronix.de \
--cc=wei.liu@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox