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 <jbeul...@suse.com> 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
signature.asc
Description: PGP signature
