Re: Tentative fix for dom0 boot problem

[Juergen Gross <jgross@xxxxxxxx>]

On 22.06.22 15:20, Julien Grall wrote:
> Hi Juergen,
>
> On 22/06/2022 13:13, Juergen Gross wrote:
> > On 22.06.22 12:50, Julien Grall wrote:
> > > On 22/06/2022 11:45, Juergen Gross wrote:
> > > > Julien,
> > > Hi Juergen,
> > >
> > > > could you please test the attached patches?
> > > I am getting the following error:
> > >
> > > (XEN) d0v0 Unhandled: vec 14, #PF[0003]
> > > (XEN) Pagetable walk from ffffffff84001000:
> > > (XEN)  L4[0x1ff] = 000000046c004067 0000000000004004
> > > (XEN)  L3[0x1fe] = 000000046c003067 0000000000004003
> > > (XEN)  L2[0x020] = 000000046c024067 0000000000004024
> > > (XEN)  L1[0x001] = 001000046c001025 0000000000004001
> > Hmm, from this data I guess this was a write to a page table.
> >
> > > (XEN) domain_crash_sync called from entry.S: fault at ffff82d040325906 
> > > x86_64/entry.S#create_bounce_frame+0x15d/0x177
> > > (XEN) Domain 0 (vcpu#0) crashed on cpu#1:
> > > (XEN) ----[ Xen-4.17-unstable  x86_64  debug=y  Tainted:   C    ]----
> > > (XEN) CPU:    1
> > > (XEN) RIP:    e033:[<ffffffff832a3481>]
> > Can you please find out the associated statement?
> arch/x86/kernel/head64.c:433
>
> This is the memset() for __brk_base.
Very weird.

In the kernel's linker script we have:

        __end_of_kernel_reserve = .;

        . = ALIGN(PAGE_SIZE);
        .brk (NOLOAD) : AT(ADDR(.brk) - LOAD_OFFSET) {
                __brk_base = .;
                . += 64 * 1024;         /* 64k alignment slop space */
                *(.bss..brk)            /* areas brk users have reserved */
                __brk_limit = .;
        }

        . = ALIGN(PAGE_SIZE);           /* keep VO_INIT_SIZE page aligned */
        _end = .;

So the area to be zeroed should be larger than 64k.

> > > (XEN) RFLAGS: 0000000000000206   EM: 1   CONTEXT: pv guest (d0v0)
> > > (XEN) rax: 0000000000000000   rbx: ffffffff84000000   rcx: 000000000002b000
> > > (XEN) rdx: ffffffff84000000   rsi: ffffffff84000000   rdi: ffffffff84001000
Just guessing I'd say that memset started at ffffffff84000000 and there are
2b000 bytes left to be cleared. A disassembly of clear_bss() would help here.

Anyway it seems as if the memset would run right into the initial page tables
supplied by the hypervisor.

Can you please post the hypervisor's console messages regarding dom0 sizes
and locations?

Could it be that the brk area is the last section relevant for loading the
kernel? In contrast to your .config, I have CONFIG_AMD_MEM_ENCRYPT defined
and this adds the .init.scratch section after the brk area. Maybe the
hypervisor is not adjusting the page table location correctly due to the
NOLOAD attribute of brk?


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature