From: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: aik@au1.ibm.com, qemu-devel@nongnu.org, groug@kaod.org,
paulus@ozlabs.org, qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v10 6/6] ppc: spapr: Handle "ibm, nmi-register" and "ibm, nmi-interlock" RTAS calls
Date: Wed, 3 Jul 2019 14:30:31 +0530 [thread overview]
Message-ID: <c8f78a4c-d4a0-10e9-e0c9-0e37e3415b5c@linux.vnet.ibm.com> (raw)
In-Reply-To: <20190703032027.GI9442@umbus.fritz.box>
On Wednesday 03 July 2019 08:50 AM, David Gibson wrote:
> On Tue, Jul 02, 2019 at 04:10:08PM +0530, Aravinda Prasad wrote:
>>
>>
>> On Tuesday 02 July 2019 09:41 AM, David Gibson wrote:
>>> On Wed, Jun 12, 2019 at 02:51:38PM +0530, Aravinda Prasad wrote:
>>>> This patch adds support in QEMU to handle "ibm,nmi-register"
>>>> and "ibm,nmi-interlock" RTAS calls and sets the default
>>>> value of SPAPR_CAP_FWNMI_MCE to SPAPR_CAP_ON for machine
>>>> type 4.0.
>>>>
>>>> The machine check notification address is saved when the
>>>> OS issues "ibm,nmi-register" RTAS call.
>>>>
>>>> This patch also handles the case when multiple processors
>>>> experience machine check at or about the same time by
>>>> handling "ibm,nmi-interlock" call. In such cases, as per
>>>> PAPR, subsequent processors serialize waiting for the first
>>>> processor to issue the "ibm,nmi-interlock" call. The second
>>>> processor that also received a machine check error waits
>>>> till the first processor is done reading the error log.
>>>> The first processor issues "ibm,nmi-interlock" call
>>>> when the error log is consumed.
>>>>
>>>> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
>>>> ---
>>>> hw/ppc/spapr.c | 6 ++++-
>>>> hw/ppc/spapr_rtas.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>> include/hw/ppc/spapr.h | 5 +++-
>>>> 3 files changed, 72 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>>>> index 3d6d139..213d493 100644
>>>> --- a/hw/ppc/spapr.c
>>>> +++ b/hw/ppc/spapr.c
>>>> @@ -2946,6 +2946,9 @@ static void spapr_machine_init(MachineState *machine)
>>>> /* Create the error string for live migration blocker */
>>>> error_setg(&spapr->fwnmi_migration_blocker,
>>>> "Live migration not supported during machine check handling");
>>>> +
>>>> + /* Register ibm,nmi-register and ibm,nmi-interlock RTAS calls */
>>>> + spapr_fwnmi_register();
>>>> }
>>>>
>>>> spapr->rtas_blob = g_malloc(spapr->rtas_size);
>>>> @@ -4408,7 +4411,7 @@ static void spapr_machine_class_init(ObjectClass *oc, void *data)
>>>> smc->default_caps.caps[SPAPR_CAP_NESTED_KVM_HV] = SPAPR_CAP_OFF;
>>>> smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_ON;
>>>> smc->default_caps.caps[SPAPR_CAP_CCF_ASSIST] = SPAPR_CAP_OFF;
>>>> - smc->default_caps.caps[SPAPR_CAP_FWNMI_MCE] = SPAPR_CAP_OFF;
>>>> + smc->default_caps.caps[SPAPR_CAP_FWNMI_MCE] = SPAPR_CAP_ON;
>>>
>>> Turning this on by default really isn't ok if it stops you running TCG
>>> guests at all.
>>
>> If so this can be "off" by default until TCG is supported.
>>
>>>
>>>> spapr_caps_add_properties(smc, &error_abort);
>>>> smc->irq = &spapr_irq_dual;
>>>> smc->dr_phb_enabled = true;
>>>> @@ -4512,6 +4515,7 @@ static void spapr_machine_3_1_class_options(MachineClass *mc)
>>>> smc->default_caps.caps[SPAPR_CAP_SBBC] = SPAPR_CAP_BROKEN;
>>>> smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_BROKEN;
>>>> smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_OFF;
>>>> + smc->default_caps.caps[SPAPR_CAP_FWNMI_MCE] = SPAPR_CAP_OFF;
>>>
>>> We're now well past 4.0, and in fact we're about to go into soft
>>> freeze for 4.1, so we're going to miss that too. So 4.1 and earlier
>>> will need to retain the old default.
>>
>> ok.
>>
>>>
>>>> }
>>>>
>>>> DEFINE_SPAPR_MACHINE(3_1, "3.1", false);
>>>> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
>>>> index a015a80..e010cb2 100644
>>>> --- a/hw/ppc/spapr_rtas.c
>>>> +++ b/hw/ppc/spapr_rtas.c
>>>> @@ -49,6 +49,7 @@
>>>> #include "hw/ppc/fdt.h"
>>>> #include "target/ppc/mmu-hash64.h"
>>>> #include "target/ppc/mmu-book3s-v3.h"
>>>> +#include "migration/blocker.h"
>>>>
>>>> static void rtas_display_character(PowerPCCPU *cpu, SpaprMachineState *spapr,
>>>> uint32_t token, uint32_t nargs,
>>>> @@ -352,6 +353,60 @@ static void rtas_get_power_level(PowerPCCPU *cpu, SpaprMachineState *spapr,
>>>> rtas_st(rets, 1, 100);
>>>> }
>>>>
>>>> +static void rtas_ibm_nmi_register(PowerPCCPU *cpu,
>>>> + SpaprMachineState *spapr,
>>>> + uint32_t token, uint32_t nargs,
>>>> + target_ulong args,
>>>> + uint32_t nret, target_ulong rets)
>>>> +{
>>>> + int ret;
>>>> + hwaddr rtas_addr = spapr_get_rtas_addr();
>>>> +
>>>> + if (!rtas_addr) {
>>>> + rtas_st(rets, 0, RTAS_OUT_NOT_SUPPORTED);
>>>> + return;
>>>> + }
>>>> +
>>>> + if (spapr_get_cap(spapr, SPAPR_CAP_FWNMI_MCE) == SPAPR_CAP_OFF) {
>>>> + rtas_st(rets, 0, RTAS_OUT_NOT_SUPPORTED);
>>>> + return;
>>>> + }
>>>> +
>>>> + ret = kvmppc_fwnmi_enable(cpu);
>>>> + if (ret == 1) {
>>>> + rtas_st(rets, 0, RTAS_OUT_NOT_SUPPORTED);
>>>
>>> I don't understand this case separate from the others. We've already
>>> set the cap, so fwnmi support should be checked and available.
>>
>> But we have not enabled fwnmi in KVM. kvmppc_fwnmi_enable() returns 1 if
>> cap_ppc_fwnmi is not available in KVM.
>
> But you've checked for the presence of the extension, yes? So a
> failure to enable the cap would be unexpected. In which case how does
> this case differ from..
No, this is the function where I check for the presence of the
extension. In kvm_arch_init() we just set cap_ppc_fwnmi to 1 if KVM
support is available, but don't take any action if unavailable.
So this case is when we are running an old version of KVM with no
cap_ppc_fwnmi support.
>
>>
>>>
>>>> + return;
>>>> + } else if (ret < 0) {
>>>> + error_report("Couldn't enable KVM FWNMI capability");
>>>> + rtas_st(rets, 0, RTAS_OUT_HW_ERROR);
>>>> + return;
>
> ..this case.
And this is when we have the KVM support but due to some problem with
either KVM or QEMU we are unable to enable cap_ppc_fwnmi.
>
>>>> + }
>>>> +
>>>> + spapr->guest_machine_check_addr = rtas_ld(args, 1);
>>>> + rtas_st(rets, 0, RTAS_OUT_SUCCESS);
>>>> +}
>>>> +
>>>> +static void rtas_ibm_nmi_interlock(PowerPCCPU *cpu,
>>>> + SpaprMachineState *spapr,
>>>> + uint32_t token, uint32_t nargs,
>>>> + target_ulong args,
>>>> + uint32_t nret, target_ulong rets)
>>>> +{
>>>> + if (spapr->guest_machine_check_addr == -1) {
>>>> + /* NMI register not called */
>>>> + rtas_st(rets, 0, RTAS_OUT_PARAM_ERROR);
>>>> + } else {
>>>> + /*
>>>> + * vCPU issuing "ibm,nmi-interlock" is done with NMI handling,
>>>> + * hence unset mc_status.
>>>> + */
>>>> + spapr->mc_status = -1;
>>>> + qemu_cond_signal(&spapr->mc_delivery_cond);
>>>> + migrate_del_blocker(spapr->fwnmi_migration_blocker);
>>>
>>> Hrm. We add the blocker at the mce request point. First, that's in
>>> another patch, which isn't great. Second, does that mean we could add
>>> multiple times if we get an MCE on multiple CPUs? Will that work and
>>> correctly match adds and removes properly?
>>
>> If it is fine to move the migration patch as the last patch in the
>> sequence, then we will have add and del blocker in the same patch.
>>
>> And yes we could add multiple times if we get MCE on multiple CPUs and
>> as all those cpus call interlock there should be matching number of
>> delete blockers.
>
> Ok, and I think adding the same pointer to the list multiple times
> will work ok.
I think so
>
> Btw, add_blocker() can fail - have you handled failure conditions?
yes, I am handling it.
>
--
Regards,
Aravinda
next prev parent reply other threads:[~2019-07-03 9:23 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-12 9:20 [Qemu-devel] [PATCH v10 0/6] target-ppc/spapr: Add FWNMI support in QEMU for PowerKVM guests Aravinda Prasad
2019-06-12 9:20 ` [Qemu-devel] [PATCH v10 1/6] Wrapper function to wait on condition for the main loop mutex Aravinda Prasad
2019-06-12 9:21 ` [Qemu-devel] [PATCH v10 2/6] ppc: spapr: Introduce FWNMI capability Aravinda Prasad
2019-07-02 3:51 ` David Gibson
2019-07-02 6:24 ` Aravinda Prasad
2019-07-03 3:03 ` David Gibson
2019-07-03 9:28 ` Aravinda Prasad
2019-07-04 1:07 ` David Gibson
2019-07-04 5:03 ` Aravinda Prasad
2019-07-05 1:07 ` David Gibson
2019-07-05 11:19 ` Aravinda Prasad
2019-07-05 13:23 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2019-07-08 10:26 ` Aravinda Prasad
2019-06-12 9:21 ` [Qemu-devel] [PATCH v10 3/6] target/ppc: Handle NMI guest exit Aravinda Prasad
2019-07-02 3:52 ` David Gibson
2019-06-12 9:21 ` [Qemu-devel] [PATCH v10 4/6] target/ppc: Build rtas error log upon an MCE Aravinda Prasad
2019-07-02 4:03 ` David Gibson
2019-07-02 9:49 ` Aravinda Prasad
2019-07-03 3:07 ` David Gibson
2019-07-03 7:16 ` Aravinda Prasad
2019-06-12 9:21 ` [Qemu-devel] [PATCH v10 5/6] migration: Include migration support for machine check handling Aravinda Prasad
2019-06-12 9:21 ` [Qemu-devel] [PATCH v10 6/6] ppc: spapr: Handle "ibm, nmi-register" and "ibm, nmi-interlock" RTAS calls Aravinda Prasad
2019-06-24 14:29 ` Greg Kurz
2019-06-25 6:16 ` Aravinda Prasad
2019-06-25 7:00 ` Greg Kurz
2019-06-26 5:13 ` [Qemu-devel] [Qemu-ppc] " Aravinda Prasad
2019-07-02 4:12 ` David Gibson
2019-07-02 4:11 ` [Qemu-devel] " David Gibson
2019-07-02 10:40 ` Aravinda Prasad
2019-07-03 3:20 ` David Gibson
2019-07-03 9:00 ` Aravinda Prasad [this message]
2019-07-04 1:12 ` David Gibson
2019-07-04 5:19 ` Aravinda Prasad
2019-07-04 18:37 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2019-07-05 11:11 ` Aravinda Prasad
2019-07-05 12:35 ` Greg Kurz
2019-07-09 6:41 ` [Qemu-devel] " David Gibson
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=c8f78a4c-d4a0-10e9-e0c9-0e37e3415b5c@linux.vnet.ibm.com \
--to=aravinda@linux.vnet.ibm.com \
--cc=aik@au1.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=groug@kaod.org \
--cc=paulus@ozlabs.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).