[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170801191144.k333twdie52arpwt@black.fi.intel.com>
Date: Tue, 1 Aug 2017 22:11:44 +0300
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Juergen Gross <jgross@...e.com>
Cc: "Kirill A. Shutemov" <kirill@...temov.name>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <ak@...ux.intel.com>,
Dave Hansen <dave.hansen@...el.com>,
Andy Lutomirski <luto@...capital.net>,
Michal Hocko <mhocko@...nel.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2 08/10] x86/mm: Replace compile-time checks for 5-level
with runtime-time
On Tue, Aug 01, 2017 at 07:14:57PM +0200, Juergen Gross wrote:
> On 01/08/17 16:44, Kirill A. Shutemov wrote:
> > On Tue, Aug 01, 2017 at 09:46:56AM +0200, Juergen Gross wrote:
> >> On 26/07/17 18:43, Kirill A. Shutemov wrote:
> >>> On Wed, Jul 26, 2017 at 09:28:16AM +0200, Juergen Gross wrote:
> >>>> On 25/07/17 11:05, Kirill A. Shutemov wrote:
> >>>>> On Tue, Jul 18, 2017 at 04:24:06PM +0200, Juergen Gross wrote:
> >>>>>> Xen PV guests will never run with 5-level-paging enabled. So I guess you
> >>>>>> can drop the complete if (IS_ENABLED(CONFIG_X86_5LEVEL)) {} block.
> >>>>>
> >>>>> There is more code to drop from mmu_pv.c.
> >>>>>
> >>>>> But while there, I thought if with boot-time 5-level paging switching we
> >>>>> can allow kernel to compile with XEN_PV and XEN_PVH, so the kernel image
> >>>>> can be used in these XEN modes with 4-level paging.
> >>>>>
> >>>>> Could you check if with the patch below we can boot in XEN_PV and XEN_PVH
> >>>>> modes?
> >>>>
> >>>> We can't. I have used your branch:
> >>>>
> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git
> >>>> la57/boot-switching/v2
> >>>>
> >>>> with this patch applied on top.
> >>>>
> >>>> Doesn't boot PV guest with X86_5LEVEL configured (very early crash).
> >>>
> >>> Hm. Okay.
> >>>
> >>> Have you tried PVH?
> >>>
> >>>> Doesn't build with X86_5LEVEL not configured:
> >>>>
> >>>> AS arch/x86/kernel/head_64.o
> >>>
> >>> I've fixed the patch and split the patch into two parts: cleanup and
> >>> re-enabling XEN_PV and XEN_PVH for X86_5LEVEL.
> >>>
> >>> There's chance that I screw somthing up in clenaup part. Could you check
> >>> that?
> >>
> >> Build is working with and without X86_5LEVEL configured.
> >>
> >> PV domU boots without X86_5LEVEL configured.
> >>
> >> PV domU crashes with X86_5LEVEL configured:
> >>
> >> xen_start_kernel()
> >> x86_64_start_reservations()
> >> start_kernel()
> >> setup_arch()
> >> early_ioremap_init()
> >> early_ioremap_pmd()
> >>
> >> In early_ioremap_pmd() there seems to be a call to p4d_val() which is an
> >> uninitialized paravirt operation in the Xen pv case.
> >
> > Thanks for testing.
> >
> > Could you check if patch below makes a difference?
>
> A little bit better. I get a panic message with backtrace now:
Are you running with 512m of ram or so?
There's known issue with sparse mem: it still allocate data structures as
if there's 52-bit phys address space even for p4d_folded case.
I'm looking this.
Try to bump memory size to 2g or so for now.
--
Kirill A. Shutemov
Powered by blists - more mailing lists