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. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
signature.asc
Description: PGP signature
