RE: [EXTERNAL] Re: [PATCH 1/2] x86/Kconfig: Allow CONFIG_X86_MPPARSE disable for OF platforms

[Saurabh Singh Sengar]

> -----Original Message-----
> From: Dave Hansen <dave.hansen@xxxxxxxxx>
> Sent: Wednesday, May 24, 2023 11:33 PM
> To: Saurabh Singh Sengar <ssengar@xxxxxxxxxxxxx>; Saurabh Sengar
> <ssengar@xxxxxxxxxxxxxxxxxxx>; tglx@xxxxxxxxxxxxx; mingo@xxxxxxxxxx;
> bp@xxxxxxxxx; dave.hansen@xxxxxxxxxxxxxxx; x86@xxxxxxxxxx;
> hpa@xxxxxxxxx; KY Srinivasan <kys@xxxxxxxxxxxxx>; Haiyang Zhang
> <haiyangz@xxxxxxxxxxxxx>; wei.liu@xxxxxxxxxx; Dexuan Cui
> <decui@xxxxxxxxxxxxx>; Michael Kelley (LINUX) <mikelley@xxxxxxxxxxxxx>;
> linux-kernel@xxxxxxxxxxxxxxx; linux-hyperv@xxxxxxxxxxxxxxx
> Subject: Re: [EXTERNAL] Re: [PATCH 1/2] x86/Kconfig: Allow
> CONFIG_X86_MPPARSE disable for OF platforms
> 
> On 5/24/23 09:23, Saurabh Singh Sengar wrote:
> >> Could you please rephrase this to be less confusing?
> >
> > Thanks for your review. Currently, in the absence of ACPI, it is
> > impossible to disable X86_MPPARSE. In the case of ACPI being enabled,
> > one has the option to either enable or disable X86_MPARSE. My
> > intention is to permit X86_MPPARSE=n for OF platforms where ACPI=n. To
> > describe the capability of choosing any desired value for MPPARSE, I used
> the term 'selectable.'
> > Perhaps 'configurable' would be a more appropriate word in this context?
> > I can fix this and include it in V2.
> 
> OK, so this particular Hyper-V setup doesn't run normal normal distro
> kernels?  It requires a very specialized kernel?  Or it's just _better_ that the
> kernel is configured this way?

This is a system where we provide isolation through VTL. More information
About VTL is here: https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/vsm#virtual-trust-level-vtl

In the context of VTL0, the system runs the normal kernel. However, for
higher VTLs, we enable the kernel with HYPERV_VTL_MODE. It's important
to note that the lower memory of the system is not included in the higher VTLs

It runs the normal kernel as part of VTL0 but for higher VTLs we run the kernel with
HYPERV_VTL_MODE enable. VTL0 is assigned to lower memory of system, the lower
memory not part of higher VTLs. However, MPARSE option disregard this and try to
scan VTL0 memory which causes issue. This will enable any system which
doesn't want lower memory to be scanned for MPPARSE for whatever reason.

> 
> >> This is also one of those patches where I wonder: Why do _you_ care
> >> about this?  Are you just trying to be nice?  Is this intended as some kind of
> cleanup?
> >
> > It solves an issue for Hyper-V VBS setup, please refer to the 2/2 of
> > this patch series.
> 
> Heh, that changelog is even more confusing than _this_ one.  It doesn't say
> that there's a problem, only that it removes "not required" code.
> 
> I'm still confused by this whole thing.

I agree the commit message could be better. And I commented below in that
thread to clarify. Hope it clarifies, please let me know if any more information is
required:

When CONFIG_X86_MPPARSE is enabled, the kernel will scan low memory,
looking for MP tables. In Hyper-V VBS setup, lower memory is assigned to VTL0.
This lower memory may contain the actual MPPARSE table for VTL0,
which can confuse the VTLx kernel and cause issues. (x > 0)