Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <23749756-022a-5574-af4d-a4a03d9542e1@intel.com>
Date:   Tue, 13 Jun 2023 10:33:07 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [PATCH v2] x86/hyperv: add noop functions to x86_init mpparse
 functions
Content-Language: en-US
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
References: <1686640391-13001-1-git-send-email-ssengar@linux.microsoft.com>
From:   Dave Hansen <dave.hansen@intel.com>
In-Reply-To: <1686640391-13001-1-git-send-email-ssengar@linux.microsoft.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.