On Sat, Oct 19, 2024 at 07:20:54PM +0100, Andrew Cooper wrote:
> pvh_init() sets up the mbi pointer, but leaves mbi_p at 0. This isn't
> compatbile with multiboot_fill_boot_info() starting from the physical address,
> in order to remove the use of the mbi pointer.
>
> Fixes: 038826b61e85 ("x86/boot: move x86 boot module counting into a new
> boot_info struct")
> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
> ---
> CC: Jan Beulich <jbeul...@suse.com>
> CC: Roger Pau Monné <roger....@citrix.com>
> CC: Daniel P. Smith <dpsm...@apertussolutions.com>
>
> This is a testiment to how tangled the boot code really is.
Did it causes crash in some boot configuration? If so, did some test
tripped on this (from what I see, not a gitlab one)?
> ---
> xen/arch/x86/setup.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 6746ed8cced6..bfede5064e8c 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1048,6 +1048,7 @@ void asmlinkage __init noreturn __start_xen(unsigned
> long mbi_p)
> {
> ASSERT(mbi_p == 0);
> pvh_init(&mbi, &mod);
> + mbi_p = __pa(mbi);
> }
> else
> {
>
> base-commit: e9f227685e7204cb2293576ee5b745b828cb3cd7
> --
> 2.39.5
>
>
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
