From: "Cédric Le Goater" <clg@kaod.org> To: Ram Pai <linuxram@us.ibm.com>, linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org Cc: aik@ozlabs.ru, andmike@linux.ibm.com, groug@kaod.org, clg@fr.ibm.com, sukadev@linux.vnet.ibm.com, bauerman@linux.ibm.com, david@gibson.dropbear.id.au Subject: Re: [RFC PATCH v1] powerpc/prom_init: disable XIVE in Secure VM. Date: Sat, 29 Feb 2020 09:27:54 +0100 [thread overview] Message-ID: <1e28fb80-7bae-8d80-1a72-f616af030aab@kaod.org> (raw) In-Reply-To: <1582962844-26333-1-git-send-email-linuxram@us.ibm.com> On 2/29/20 8:54 AM, Ram Pai wrote: > XIVE is not correctly enabled for Secure VM in the KVM Hypervisor yet. > > Hence Secure VM, must always default to XICS interrupt controller. have you tried XIVE emulation 'kernel-irqchip=off' ? > If XIVE is requested through kernel command line option "xive=on", > override and turn it off. This is incorrect. It is negotiated through CAS depending on the FW capabilities and the KVM capabilities. > If XIVE is the only supported platform interrupt controller; specified > through qemu option "ic-mode=xive", simply abort. Otherwise default to > XICS. I don't think it is a good approach to downgrade the guest kernel capabilities this way. PAPR has specified the CAS negotiation process for this purpose. It comes in two parts under KVM. First the KVM hypervisor advertises or not a capability to QEMU. The second is the CAS negotiation process between QEMU and the guest OS. The SVM specifications might not be complete yet and if some features are incompatible, I think we should modify the capabilities advertised by the hypervisor : no XIVE in case of SVM. QEMU will automatically use the fallback path and emulate the XIVE device, same as setting 'kernel-irqchip=off'. This is how KVM operates on Boston systems today which do not have the right level of FW to support migration. XIVE is emulated. It will give SVM a working default without any changes in QEMU or the guest. Now, if one needs more performance, accelerated xics should be activated on the command line with 'xive=off'. I understand that SVM requires FW support. Do we have a SVM capability returned to QEMU ? That might have been addressed in other patches. Thanks, C. > > Cc: kvm-ppc@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com> > Cc: Michael Anderson <andmike@linux.ibm.com> > Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> > Cc: Alexey Kardashevskiy <aik@ozlabs.ru> > Cc: Paul Mackerras <paulus@ozlabs.org> > Cc: Greg Kurz <groug@kaod.org> > Cc: Cedric Le Goater <clg@fr.ibm.com> > Cc: David Gibson <david@gibson.dropbear.id.au> > Signed-off-by: Ram Pai <linuxram@us.ibm.com> > --- > arch/powerpc/kernel/prom_init.c | 43 ++++++++++++++++++++++++++++------------- > 1 file changed, 30 insertions(+), 13 deletions(-) > > diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c > index 5773453..dd96c82 100644 > --- a/arch/powerpc/kernel/prom_init.c > +++ b/arch/powerpc/kernel/prom_init.c > @@ -805,6 +805,18 @@ static void __init early_cmdline_parse(void) > #endif > } > > +#ifdef CONFIG_PPC_SVM > + opt = prom_strstr(prom_cmd_line, "svm="); > + if (opt) { > + bool val; > + > + opt += sizeof("svm=") - 1; > + if (!prom_strtobool(opt, &val)) > + prom_svm_enable = val; > + prom_printf("svm =%d\n", prom_svm_enable); > + } > +#endif /* CONFIG_PPC_SVM */ > + > #ifdef CONFIG_PPC_PSERIES > prom_radix_disable = !IS_ENABLED(CONFIG_PPC_RADIX_MMU_DEFAULT); > opt = prom_strstr(prom_cmd_line, "disable_radix"); > @@ -823,23 +835,22 @@ static void __init early_cmdline_parse(void) > if (prom_radix_disable) > prom_debug("Radix disabled from cmdline\n"); > > - opt = prom_strstr(prom_cmd_line, "xive=off"); > - if (opt) { > +#ifdef CONFIG_PPC_SVM > + if (prom_svm_enable) { > prom_xive_disable = true; > - prom_debug("XIVE disabled from cmdline\n"); > + prom_debug("XIVE disabled in Secure VM\n"); > } > -#endif /* CONFIG_PPC_PSERIES */ > - > -#ifdef CONFIG_PPC_SVM > - opt = prom_strstr(prom_cmd_line, "svm="); > - if (opt) { > - bool val; > +#endif /* CONFIG_PPC_SVM */ > > - opt += sizeof("svm=") - 1; > - if (!prom_strtobool(opt, &val)) > - prom_svm_enable = val; > + if (!prom_xive_disable) { > + opt = prom_strstr(prom_cmd_line, "xive=off"); > + if (opt) { > + prom_xive_disable = true; > + prom_debug("XIVE disabled from cmdline\n"); > + } > } > -#endif /* CONFIG_PPC_SVM */ > + > +#endif /* CONFIG_PPC_PSERIES */ > } > > #ifdef CONFIG_PPC_PSERIES > @@ -1251,6 +1262,12 @@ static void __init prom_parse_xive_model(u8 val, > break; > case OV5_FEAT(OV5_XIVE_EXPLOIT): /* Only Exploitation mode */ > prom_debug("XIVE - exploitation mode supported\n"); > + > +#ifdef CONFIG_PPC_SVM > + if (prom_svm_enable) > + prom_panic("WARNING: xive unsupported in Secure VM\n"); > +#endif /* CONFIG_PPC_SVM */ > + > if (prom_xive_disable) { > /* > * If we __have__ to do XIVE, we're better off ignoring >
WARNING: multiple messages have this Message-ID (diff)
From: "Cédric Le Goater" <clg@kaod.org> To: Ram Pai <linuxram@us.ibm.com>, linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org Cc: aik@ozlabs.ru, andmike@linux.ibm.com, groug@kaod.org, clg@fr.ibm.com, sukadev@linux.vnet.ibm.com, bauerman@linux.ibm.com, david@gibson.dropbear.id.au Subject: Re: [RFC PATCH v1] powerpc/prom_init: disable XIVE in Secure VM. Date: Sat, 29 Feb 2020 08:27:54 +0000 [thread overview] Message-ID: <1e28fb80-7bae-8d80-1a72-f616af030aab@kaod.org> (raw) In-Reply-To: <1582962844-26333-1-git-send-email-linuxram@us.ibm.com> On 2/29/20 8:54 AM, Ram Pai wrote: > XIVE is not correctly enabled for Secure VM in the KVM Hypervisor yet. > > Hence Secure VM, must always default to XICS interrupt controller. have you tried XIVE emulation 'kernel-irqchip=off' ? > If XIVE is requested through kernel command line option "xive=on", > override and turn it off. This is incorrect. It is negotiated through CAS depending on the FW capabilities and the KVM capabilities. > If XIVE is the only supported platform interrupt controller; specified > through qemu option "ic-mode=xive", simply abort. Otherwise default to > XICS. I don't think it is a good approach to downgrade the guest kernel capabilities this way. PAPR has specified the CAS negotiation process for this purpose. It comes in two parts under KVM. First the KVM hypervisor advertises or not a capability to QEMU. The second is the CAS negotiation process between QEMU and the guest OS. The SVM specifications might not be complete yet and if some features are incompatible, I think we should modify the capabilities advertised by the hypervisor : no XIVE in case of SVM. QEMU will automatically use the fallback path and emulate the XIVE device, same as setting 'kernel-irqchip=off'. This is how KVM operates on Boston systems today which do not have the right level of FW to support migration. XIVE is emulated. It will give SVM a working default without any changes in QEMU or the guest. Now, if one needs more performance, accelerated xics should be activated on the command line with 'xive=off'. I understand that SVM requires FW support. Do we have a SVM capability returned to QEMU ? That might have been addressed in other patches. Thanks, C. > > Cc: kvm-ppc@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com> > Cc: Michael Anderson <andmike@linux.ibm.com> > Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> > Cc: Alexey Kardashevskiy <aik@ozlabs.ru> > Cc: Paul Mackerras <paulus@ozlabs.org> > Cc: Greg Kurz <groug@kaod.org> > Cc: Cedric Le Goater <clg@fr.ibm.com> > Cc: David Gibson <david@gibson.dropbear.id.au> > Signed-off-by: Ram Pai <linuxram@us.ibm.com> > --- > arch/powerpc/kernel/prom_init.c | 43 ++++++++++++++++++++++++++++------------- > 1 file changed, 30 insertions(+), 13 deletions(-) > > diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c > index 5773453..dd96c82 100644 > --- a/arch/powerpc/kernel/prom_init.c > +++ b/arch/powerpc/kernel/prom_init.c > @@ -805,6 +805,18 @@ static void __init early_cmdline_parse(void) > #endif > } > > +#ifdef CONFIG_PPC_SVM > + opt = prom_strstr(prom_cmd_line, "svm="); > + if (opt) { > + bool val; > + > + opt += sizeof("svm=") - 1; > + if (!prom_strtobool(opt, &val)) > + prom_svm_enable = val; > + prom_printf("svm =%d\n", prom_svm_enable); > + } > +#endif /* CONFIG_PPC_SVM */ > + > #ifdef CONFIG_PPC_PSERIES > prom_radix_disable = !IS_ENABLED(CONFIG_PPC_RADIX_MMU_DEFAULT); > opt = prom_strstr(prom_cmd_line, "disable_radix"); > @@ -823,23 +835,22 @@ static void __init early_cmdline_parse(void) > if (prom_radix_disable) > prom_debug("Radix disabled from cmdline\n"); > > - opt = prom_strstr(prom_cmd_line, "xive=off"); > - if (opt) { > +#ifdef CONFIG_PPC_SVM > + if (prom_svm_enable) { > prom_xive_disable = true; > - prom_debug("XIVE disabled from cmdline\n"); > + prom_debug("XIVE disabled in Secure VM\n"); > } > -#endif /* CONFIG_PPC_PSERIES */ > - > -#ifdef CONFIG_PPC_SVM > - opt = prom_strstr(prom_cmd_line, "svm="); > - if (opt) { > - bool val; > +#endif /* CONFIG_PPC_SVM */ > > - opt += sizeof("svm=") - 1; > - if (!prom_strtobool(opt, &val)) > - prom_svm_enable = val; > + if (!prom_xive_disable) { > + opt = prom_strstr(prom_cmd_line, "xive=off"); > + if (opt) { > + prom_xive_disable = true; > + prom_debug("XIVE disabled from cmdline\n"); > + } > } > -#endif /* CONFIG_PPC_SVM */ > + > +#endif /* CONFIG_PPC_PSERIES */ > } > > #ifdef CONFIG_PPC_PSERIES > @@ -1251,6 +1262,12 @@ static void __init prom_parse_xive_model(u8 val, > break; > case OV5_FEAT(OV5_XIVE_EXPLOIT): /* Only Exploitation mode */ > prom_debug("XIVE - exploitation mode supported\n"); > + > +#ifdef CONFIG_PPC_SVM > + if (prom_svm_enable) > + prom_panic("WARNING: xive unsupported in Secure VM\n"); > +#endif /* CONFIG_PPC_SVM */ > + > if (prom_xive_disable) { > /* > * If we __have__ to do XIVE, we're better off ignoring >
next prev parent reply other threads:[~2020-02-29 8:47 UTC|newest] Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-29 7:54 [RFC PATCH v1] powerpc/prom_init: disable XIVE in Secure VM Ram Pai 2020-02-29 7:54 ` Ram Pai 2020-02-29 8:27 ` Cédric Le Goater [this message] 2020-02-29 8:27 ` Cédric Le Goater 2020-02-29 22:51 ` Ram Pai 2020-02-29 22:51 ` Ram Pai 2020-03-02 7:34 ` Cédric Le Goater 2020-03-02 7:34 ` Cédric Le Goater 2020-03-02 20:54 ` Greg Kurz 2020-03-02 20:54 ` Greg Kurz 2020-03-02 23:32 ` David Gibson 2020-03-02 23:32 ` David Gibson 2020-03-03 6:50 ` Cédric Le Goater 2020-03-03 6:50 ` Cédric Le Goater 2020-03-03 17:02 ` Ram Pai 2020-03-03 17:02 ` Ram Pai 2020-03-03 17:45 ` Greg Kurz 2020-03-03 17:45 ` Greg Kurz 2020-03-03 18:56 ` Ram Pai 2020-03-03 18:56 ` Ram Pai 2020-03-04 10:59 ` Greg Kurz 2020-03-04 10:59 ` Greg Kurz 2020-03-04 15:13 ` Ram Pai 2020-03-04 15:13 ` Ram Pai 2020-03-04 15:37 ` Ram Pai 2020-03-04 15:37 ` Ram Pai 2020-03-04 15:56 ` Cédric Le Goater 2020-03-04 15:56 ` Cédric Le Goater 2020-03-04 23:55 ` David Gibson 2020-03-04 23:55 ` David Gibson 2020-03-05 7:15 ` Cédric Le Goater 2020-03-05 7:15 ` Cédric Le Goater 2020-03-05 15:15 ` Ram Pai 2020-03-05 15:15 ` Ram Pai 2020-03-05 15:36 ` Cédric Le Goater 2020-03-05 15:36 ` Cédric Le Goater 2020-03-03 19:18 ` [EXTERNAL] " Cédric Le Goater 2020-03-03 19:18 ` Cédric Le Goater 2020-03-04 8:34 ` Greg Kurz 2020-03-04 8:34 ` Greg Kurz 2020-03-03 19:08 ` Cédric Le Goater 2020-03-03 19:08 ` Cédric Le Goater 2020-03-03 20:29 ` Ram Pai 2020-03-03 20:29 ` Ram Pai 2020-03-05 11:41 ` Cédric Le Goater 2020-03-05 11:41 ` Cédric Le Goater -- strict thread matches above, loose matches on Subject: below -- 2020-02-29 7:27 Ram Pai
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1e28fb80-7bae-8d80-1a72-f616af030aab@kaod.org \ --to=clg@kaod.org \ --cc=aik@ozlabs.ru \ --cc=andmike@linux.ibm.com \ --cc=bauerman@linux.ibm.com \ --cc=clg@fr.ibm.com \ --cc=david@gibson.dropbear.id.au \ --cc=groug@kaod.org \ --cc=kvm-ppc@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=linuxram@us.ibm.com \ --cc=sukadev@linux.vnet.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.