From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37942) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwwEf-0001bR-U6 for qemu-devel@nongnu.org; Thu, 12 Nov 2015 13:04:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwwEc-0003qO-NH for qemu-devel@nongnu.org; Thu, 12 Nov 2015 13:04:37 -0500 Received: from e39.co.us.ibm.com ([32.97.110.160]:39205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwwEc-0003pY-HR for qemu-devel@nongnu.org; Thu, 12 Nov 2015 13:04:34 -0500 Received: from localhost by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 12 Nov 2015 11:04:31 -0700 Message-ID: <5644D49E.4070604@linux.vnet.ibm.com> Date: Thu, 12 Nov 2015 23:34:14 +0530 From: Aravinda Prasad MIME-Version: 1.0 References: <20151111171135.4328.41819.stgit@aravindap> <20151111171544.4328.22074.stgit@aravindap> <20151112040243.GM5852@voom.redhat.com> In-Reply-To: <20151112040243.GM5852@voom.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/4] spapr: Handle "ibm, nmi-register" and "ibm, nmi-interlock" RTAS calls List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: benh@au1.ibm.com, aik@ozlabs.ru, agraf@suse.de, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, paulus@samba.org, sam.bobroff@au1.ibm.com On Thursday 12 November 2015 09:32 AM, David Gibson wrote: > On Wed, Nov 11, 2015 at 10:45:44PM +0530, Aravinda Prasad wrote: >> This patch adds support in QEMU to handle "ibm,nmi-register" >> and "ibm,nmi-interlock" RTAS calls. >> >> 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 waits till the first processor, which also >> received a machine check error, is done reading the error >> log. The first processor issues "ibm,nmi-interlock" call >> when the error log is consumed. This patch implements the >> releasing part of the error-log while subsequent patch >> (which builds error log) handles the locking part. >> >> Signed-off-by: Aravinda Prasad >> --- >> hw/ppc/spapr_rtas.c | 29 +++++++++++++++++++++++++++++ >> include/hw/ppc/spapr.h | 8 +++++++- >> 2 files changed, 36 insertions(+), 1 deletion(-) >> >> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c >> index 9869bc9..fd4d2af 100644 >> --- a/hw/ppc/spapr_rtas.c >> +++ b/hw/ppc/spapr_rtas.c >> @@ -597,6 +597,31 @@ out: >> rtas_st(rets, 0, rc); >> } >> >> +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) >> +{ >> + qemu_mutex_init(&spapr->mc_in_progress); >> + 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) >> +{ >> + /* >> + * VCPU issuing "ibm,nmi-interlock" is done with NMI handling, >> + * hence unlock mc_in_progress. >> + */ >> + qemu_mutex_unlock(&spapr->mc_in_progress); > > Hrm... allowing the guest direct control over a qemu internal mutex > sets off alarm bells for me. > > It could be ok, depending on exactly where the mutex is taken, and > whether it has a timeout and so forth, but it makes me nervous. > > If nothing else this needs some substantial comments explaining the > locking scheme and why it's safe to give userspace direct control over > the unlock. I will follow the approach suggested by Thomas which eliminates direct control of qemu internal lock by guest. Regards, Aravinda > >> + rtas_st(rets, 0, RTAS_OUT_SUCCESS); >> +} >> + >> static struct rtas_call { >> const char *name; >> spapr_rtas_fn fn; >> @@ -747,6 +772,10 @@ static void core_rtas_register_types(void) >> rtas_get_sensor_state); >> spapr_rtas_register(RTAS_IBM_CONFIGURE_CONNECTOR, "ibm,configure-connector", >> rtas_ibm_configure_connector); >> + spapr_rtas_register(RTAS_IBM_NMI_REGISTER, "ibm,nmi-register", >> + rtas_ibm_nmi_register); >> + spapr_rtas_register(RTAS_IBM_NMI_INTERLOCK, "ibm,nmi-interlock", >> + rtas_ibm_nmi_interlock); >> } >> >> type_init(core_rtas_register_types) >> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h >> index b5cadd7..0a31d15 100644 >> --- a/include/hw/ppc/spapr.h >> +++ b/include/hw/ppc/spapr.h >> @@ -74,6 +74,10 @@ struct sPAPRMachineState { >> /* RTAS state */ >> QTAILQ_HEAD(, sPAPRConfigureConnectorState) ccs_list; >> >> + /* State related to "ibm,nmi-register" and "ibm,nmi-interlock" calls */ >> + target_ulong guest_machine_check_addr; >> + QemuMutex mc_in_progress; >> + >> /*< public >*/ >> char *kvm_type; >> }; >> @@ -458,8 +462,10 @@ int spapr_allocate_irq_block(int num, bool lsi, bool msi); >> #define RTAS_IBM_SET_SLOT_RESET (RTAS_TOKEN_BASE + 0x23) >> #define RTAS_IBM_CONFIGURE_PE (RTAS_TOKEN_BASE + 0x24) >> #define RTAS_IBM_SLOT_ERROR_DETAIL (RTAS_TOKEN_BASE + 0x25) >> +#define RTAS_IBM_NMI_REGISTER (RTAS_TOKEN_BASE + 0x26) >> +#define RTAS_IBM_NMI_INTERLOCK (RTAS_TOKEN_BASE + 0x27) >> >> -#define RTAS_TOKEN_MAX (RTAS_TOKEN_BASE + 0x26) >> +#define RTAS_TOKEN_MAX (RTAS_TOKEN_BASE + 0x28) >> >> /* RTAS ibm,get-system-parameter token values */ >> #define RTAS_SYSPARM_SPLPAR_CHARACTERISTICS 20 >> > -- Regards, Aravinda