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 :(
Regards,
Jason
