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@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
> 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@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
