Re: E820 memory allocation issue on Threadripper platforms

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Mar 12, 2024 at 05:07:12PM -0400, Jason Andryuk wrote:
> On 2024-03-10 10:06, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 19, 2024 at 02:40:06PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote:
> > > > On Wed, Jan 17, 2024 at 3:46 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> > > > > On 17.01.2024 07:12, Patrick Plenefisch wrote:
> > > > > > As someone who hasn't built a kernel in over a decade, should I 
> > > > > > figure
> > > > > out
> > > > > > how to do a kernel build with CONFIG_PHYSICAL_START=0x2000000 and 
> > > > > > report
> > > > > > back?
> > > > > 
> > > > > That was largely a suggestion to perhaps allow you to gain some
> > > > > workable setup. It would be of interest to us largely for 
> > > > > completeness.
> > > > > 
> > > > 
> > > > Typo aside, setting the boot to 2MiB works! It works better for PV
> > > 
> > > Are there any downsides of running kernel with
> > > CONFIG_PHYSICAL_START=0x200000? I can confirm it fixes the issue on
> > > another affected system, and if there aren't any practical downsides,
> > > I'm tempted to change it the default kernel in Qubes OS.
> > 
> > I have the answer here: CONFIG_PHYSICAL_START=0x200000 breaks booting
> > Xen in KVM with OVMF. There, the memory map has:
> > (XEN)  0000000100000-00000007fffff type=7 attr=000000000000000f
> > (XEN)  0000000800000-0000000807fff type=10 attr=000000000000000f
> > (XEN)  0000000808000-000000080afff type=7 attr=000000000000000f
> > (XEN)  000000080b000-000000080bfff type=10 attr=000000000000000f
> > (XEN)  000000080c000-000000080ffff type=7 attr=000000000000000f
> > (XEN)  0000000810000-00000008fffff type=10 attr=000000000000000f
> > (XEN)  0000000900000-00000015fffff type=4 attr=000000000000000f
> > 
> > So, starting at 0x1000000 worked since type=4 (boot service data) is
> > available at that time already, but with 0x200000 it conflicts with
> > those AcpiNvs areas around 0x800000.
> > 
> > I'm cc-ing Jason since I see he claimed relevant gitlab issue. This
> > conflict at least gives easy test environment with console logged to a
> > file.
> 
> Thanks.  I actually hacked Xen to reserve memory ranges in the e820 to
> repro.
> 
> I claimed the *PVH* Dom0 gitlab issue.  PV is outside of my scope :(

That's not bad either, it means we're getting closer to usable PVH dom0
:)

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature