* Re: [Qemu-devel] [PATCH] spapr: don't call KVM_PPC_CONFIGURE_V3_MMU if HPT is in userspace
2018-05-25 12:54 [Qemu-devel] [PATCH] spapr: don't call KVM_PPC_CONFIGURE_V3_MMU if HPT is in userspace Greg Kurz
@ 2018-05-25 14:13 ` Laurent Vivier
2018-05-26 9:00 ` Greg Kurz
2018-05-29 8:25 ` Laurent Vivier
2018-06-04 23:42 ` David Gibson
2 siblings, 1 reply; 7+ messages in thread
From: Laurent Vivier @ 2018-05-25 14:13 UTC (permalink / raw)
To: Greg Kurz, qemu-devel
Cc: qemu-ppc, David Gibson, Michael Roth, Paul Mackerras, qemu-stable
On 25/05/2018 14:54, 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);
> }
>
I'm wondering if you should use kvmppc_has_cap_mmu_hash_v3() instead?
Thanks,
Laurent
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Qemu-devel] [PATCH] spapr: don't call KVM_PPC_CONFIGURE_V3_MMU if HPT is in userspace
2018-05-25 14:13 ` Laurent Vivier
@ 2018-05-26 9:00 ` Greg Kurz
0 siblings, 0 replies; 7+ messages in thread
From: Greg Kurz @ 2018-05-26 9:00 UTC (permalink / raw)
To: Laurent Vivier
Cc: qemu-devel, qemu-ppc, David Gibson, Michael Roth, Paul Mackerras,
qemu-stable
On Fri, 25 May 2018 16:13:13 +0200
Laurent Vivier <lvivier@redhat.com> wrote:
> On 25/05/2018 14:54, 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);
> > }
> >
>
> I'm wondering if you should use kvmppc_has_cap_mmu_hash_v3() instead?
>
The meaning of KVM_CAP_PPC_HASH_MMU_V3 is basically: KVM supports POWER9
hash... even if that would *work* when using PR KVM, I'm not sure this
helps to understand.
The true reason for not calling kvmppc_configure_v3_mmu() is that we
already know that we're using a QEMU-side HPT.
> Thanks,
> Laurent
Cheers,
--
Greg
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] [PATCH] spapr: don't call KVM_PPC_CONFIGURE_V3_MMU if HPT is in userspace
2018-05-25 12:54 [Qemu-devel] [PATCH] spapr: don't call KVM_PPC_CONFIGURE_V3_MMU if HPT is in userspace Greg Kurz
2018-05-25 14:13 ` Laurent Vivier
@ 2018-05-29 8:25 ` Laurent Vivier
2018-06-04 23:42 ` David Gibson
2 siblings, 0 replies; 7+ messages in thread
From: Laurent Vivier @ 2018-05-29 8:25 UTC (permalink / raw)
To: Greg Kurz, qemu-devel
Cc: qemu-ppc, David Gibson, Michael Roth, Paul Mackerras, qemu-stable
On 25/05/2018 14:54, 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);
> }
>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Qemu-devel] [PATCH] spapr: don't call KVM_PPC_CONFIGURE_V3_MMU if HPT is in userspace
2018-05-25 12:54 [Qemu-devel] [PATCH] spapr: don't call KVM_PPC_CONFIGURE_V3_MMU if HPT is in userspace Greg Kurz
2018-05-25 14:13 ` Laurent Vivier
2018-05-29 8:25 ` Laurent Vivier
@ 2018-06-04 23:42 ` David Gibson
2018-06-05 9:14 ` Greg Kurz
2 siblings, 1 reply; 7+ messages in thread
From: David Gibson @ 2018-06-04 23:42 UTC (permalink / raw)
To: Greg Kurz
Cc: qemu-devel, qemu-ppc, Laurent Vivier, Michael Roth,
Paul Mackerras, qemu-stable
[-- Attachment #1: Type: text/plain, Size: 3247 bytes --]
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.
> }
>
--
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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Qemu-devel] [PATCH] spapr: don't call KVM_PPC_CONFIGURE_V3_MMU if HPT is in userspace
2018-06-04 23:42 ` David Gibson
@ 2018-06-05 9:14 ` Greg Kurz
2018-06-06 1:43 ` David Gibson
0 siblings, 1 reply; 7+ messages in thread
From: Greg Kurz @ 2018-06-05 9:14 UTC (permalink / raw)
To: David Gibson
Cc: qemu-devel, qemu-ppc, Laurent Vivier, Michael Roth,
Paul Mackerras, qemu-stable
[-- Attachment #1: Type: text/plain, Size: 3707 bytes --]
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 ?
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.
> > }
> >
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Qemu-devel] [PATCH] spapr: don't call KVM_PPC_CONFIGURE_V3_MMU if HPT is in userspace
2018-06-05 9:14 ` Greg Kurz
@ 2018-06-06 1:43 ` David Gibson
0 siblings, 0 replies; 7+ messages in thread
From: David Gibson @ 2018-06-06 1:43 UTC (permalink / raw)
To: Greg Kurz
Cc: qemu-devel, qemu-ppc, Laurent Vivier, Michael Roth,
Paul Mackerras, qemu-stable
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread