Re: [Qemu-devel] [PATCH] spapr: don't call KVM_PPC_CONFIGURE_V3_MMU if HPT is in userspace

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 4293 bytes --]

On Tue, Jun 05, 2018 at 11:14:53AM +0200, Greg Kurz wrote:
> On Tue, 5 Jun 2018 09:42:11 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Fri, May 25, 2018 at 02:54:12PM +0200, Greg Kurz wrote:
> > > Since the kernel commit "dbfcf3cb9c68 powerpc/64: Call H_REGISTER_PROC_TBL
> > > when running as a HPT guest on POWER9", a nested guest running with PR KVM
> > > hangs at boot:
> > > 
> > > Preparing to boot Linux version 4.16.0-kvm-pr-hang-gku+ (greg@qemu2222.boston16) (gcc version 8.1.1 20180502 (Red Hat 8.1.1-1) (GCC)) #19 SMP Fri May 25 08:41:55 CEST 2018
> > > Detected machine type: 0000000000000101
> > > command line: root=UUID=22128c5c-30b1-4e0a-ac16-95853df31131 ro rhgb console=hvc0 early_printk disable-radix=on
> > > Max number of cores passed to firmware: 1024 (NR_CPUS = 1024)
> > > Calling ibm,client-architecture-support... done
> > > memory layout at init:
> > >   memory_limit : 0000000000000000 (16 MB aligned)
> > >   alloc_bottom : 0000000001b80000
> > >   alloc_top    : 0000000030000000
> > >   alloc_top_hi : 0000000100000000
> > >   rmo_top      : 0000000030000000
> > >   ram_top      : 0000000100000000
> > > instantiating rtas at 0x000000002fff0000... done
> > > prom_hold_cpus: skipped
> > > copying OF device tree...
> > > Building dt strings...
> > > Building dt structure...
> > > Device tree strings 0x0000000003d90000 -> 0x0000000003d90abb
> > > Device tree struct  0x0000000003da0000 -> 0x0000000003db0000
> > > Quiescing Open Firmware ...
> > > Booting Linux via __start() @ 0x0000000000400000 ...
> > > 
> > > This happens because the H_REGISTER_PROC_TBL implementation in QEMU
> > > always call KVM_PPC_CONFIGURE_V3_MMU when KVM is present. This fails
> > > in the case of PR KVM, which doesn't implement it, and QEMU returns
> > > H_PARAMETER to the guest, which is a BUG() condition in linux.
> > > 
> > > In the case of PR, the HPT is allocated in userspace by QEMU, so it
> > > doesn't make sense to call KVM_PPC_CONFIGURE_V3_MMU in the first
> > > place. So, skip it in this case and let the guest boot.
> > > 
> > > Signed-off-by: Greg Kurz <groug@kaod.org>
> > > ---
> > > 
> > > Note that PR KVM requires this patch from Paul to work on POWER9:
> > > 
> > >     https://patchwork.ozlabs.org/patch/916766/
> > > 
> > > The original request was coming from people who want to run openQA in
> > > fedora28 under PowerVM on a POWER9 system. This requires PR KVM, which
> > > will be running in HPT-mode since pHyp doesn't do radix.
> > > 
> > > Cc'ing stable because fedora28 ships QEMU 2.11.x.
> > > ---
> > >  hw/ppc/spapr_hcall.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> > > index 022f6d810182..12cbb317e5e8 100644
> > > --- a/hw/ppc/spapr_hcall.c
> > > +++ b/hw/ppc/spapr_hcall.c
> > > @@ -1420,7 +1420,7 @@ static target_ulong h_register_process_table(PowerPCCPU *cpu,
> > >                    ((flags & FLAG_GTSE) ? LPCR_GTSE : 0),
> > >                    LPCR_UPRT | LPCR_GTSE);
> > >  
> > > -    if (kvm_enabled()) {
> > > +    if (kvm_enabled() && !spapr->htab) {
> > >          return kvmppc_configure_v3_mmu(cpu, flags & FLAG_RADIX,
> > >                                         flags & FLAG_GTSE, cproc);  
> > 
> > Won't this also omit the configure MMU call if the guest is in radix
> > mode?  We don't want that.
> > 
> 
> Hmm... not sure how we can have an HPT allocated in userspace if the
> guest is radix... or maybe if the guest was hash and then it is
> rebooted with a new kernel that only supports radix ?

Oops, got my sense reversed.  Rather, couldn't this call
configure_v3_mmu() on PR when you do have a Radix guest, which would
still cause problems.

> Anyway, Paul added a minimal implementation of KVM_PPC_CONFIGURE_V3_MMU
> to PR KVM, that allow nested guests to run recent kernels:
> 
> https://patchwork.ozlabs.org/patch/922688/
> 
> So I guess we don't need to patch QEMU.

Yeah, I think that's a better solution.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]