From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>, qemu-devel@nongnu.org
Cc: Tyrel Datwyler <turtle.in.the.kernel@gmail.com>,
Benjamin Herrenschmidt <benh@au1.ibm.com>,
qemu-ppc@nongnu.org, Anton Blanchard <anton@samba.org>,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH v5] ppc: spapr-rtas - implement os-term rtas call
Date: Thu, 03 Jul 2014 13:41:28 +1000 [thread overview]
Message-ID: <53B4D0E8.5070600@ozlabs.ru> (raw)
In-Reply-To: <1404117329-7899-1-git-send-email-nikunj@linux.vnet.ibm.com>
On 06/30/2014 06:35 PM, Nikunj A Dadhania wrote:
> PAPR compliant guest calls this in absence of kdump. This finally
> reaches the guest and can be handled according to the policies set by
> higher level tools(like taking dump) for further analysis by tools like
> crash.
>
> Linux kernel calls ibm,os-term when extended property of os-term is set.
> This makes sure that a return to the linux kernel is gauranteed.
>
> CC: Benjamin Herrenschmidt <benh@au1.ibm.com>
> CC: Anton Blanchard <anton@samba.org>
> CC: Alexander Graf <agraf@suse.de>
> CC: Tyrel Datwyler <turtle.in.the.kernel@gmail.com>
> Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
>
> ---
>
> v2: rebase to ppcnext
> v3: Do not stop the VM, and update comments
> v4: update spapr_register_rtas and qapi_event changes
> v5: set ibm,extended-os-term as null encoded property
> ---
> hw/ppc/spapr.c | 9 +++++++++
> hw/ppc/spapr_rtas.c | 15 +++++++++++++++
> include/hw/ppc/spapr.h | 1 -
> 3 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 307c58d..e6c9014 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -520,6 +520,15 @@ static void *spapr_create_fdt_skel(hwaddr initrd_base,
>
> _FDT((fdt_property_cell(fdt, "rtas-error-log-max", RTAS_ERROR_LOG_MAX)));
>
> + /*
> + * According to PAPR, rtas ibm,os-term, does not gaurantee a return
> + * back to the guest cpu.
> + *
> + * While an additional ibm,extended-os-term property indicates that
> + * rtas call return will always occur. Set this property.
> + */
> + _FDT((fdt_property(fdt, "ibm,extended-os-term", NULL, 0)));
> +
> _FDT((fdt_end_node(fdt)));
>
> /* interrupt controller */
> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
> index 9ba1ba6..2ec2a8e 100644
> --- a/hw/ppc/spapr_rtas.c
> +++ b/hw/ppc/spapr_rtas.c
> @@ -277,6 +277,19 @@ static void rtas_ibm_set_system_parameter(PowerPCCPU *cpu,
> rtas_st(rets, 0, ret);
> }
>
> +static void rtas_ibm_os_term(PowerPCCPU *cpu,
> + sPAPREnvironment *spapr,
> + uint32_t token, uint32_t nargs,
> + target_ulong args,
> + uint32_t nret, target_ulong rets)
> +{
> + target_ulong ret = 0;
> +
> + qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_PAUSE, &error_abort);
> +
> + rtas_st(rets, 0, ret);
> +}
> +
> static struct rtas_call {
> const char *name;
> spapr_rtas_fn fn;
> @@ -404,6 +417,8 @@ static void core_rtas_register_types(void)
> spapr_rtas_register(RTAS_IBM_SET_SYSTEM_PARAMETER,
> "ibm,set-system-parameter",
> rtas_ibm_set_system_parameter);
> + spapr_rtas_register(RTAS_IBM_OS_TERM, "ibm,os-term",
> + rtas_ibm_os_term);
> }
>
> type_init(core_rtas_register_types)
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index bbba51a..4e96381 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -382,7 +382,6 @@ int spapr_allocate_irq_block(int num, bool lsi, bool msi);
> #define RTAS_GET_SENSOR_STATE (RTAS_TOKEN_BASE + 0x1D)
> #define RTAS_IBM_CONFIGURE_CONNECTOR (RTAS_TOKEN_BASE + 0x1E)
> #define RTAS_IBM_OS_TERM (RTAS_TOKEN_BASE + 0x1F)
> -#define RTAS_IBM_EXTENDED_OS_TERM (RTAS_TOKEN_BASE + 0x20)
So we never ever going to implement this RTAS call?
I'd keep the number.
>
> #define RTAS_TOKEN_MAX (RTAS_TOKEN_BASE + 0x21)
>
>
--
Alexey
next prev parent reply other threads:[~2014-07-03 3:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-30 8:35 [Qemu-devel] [PATCH v5] ppc: spapr-rtas - implement os-term rtas call Nikunj A Dadhania
2014-06-30 9:11 ` Alexander Graf
2014-06-30 9:25 ` Nikunj A Dadhania
2014-06-30 12:05 ` Alexander Graf
2014-06-30 15:49 ` Tyrel Datwyler
2014-06-30 16:24 ` Alexander Graf
2014-07-01 3:20 ` Nikunj A Dadhania
2014-07-01 5:10 ` Alexander Graf
2014-07-03 3:41 ` Alexey Kardashevskiy [this message]
2014-07-03 3:48 ` Alexey Kardashevskiy
2014-07-03 5:27 ` Nikunj A Dadhania
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=53B4D0E8.5070600@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=agraf@suse.de \
--cc=anton@samba.org \
--cc=benh@au1.ibm.com \
--cc=nikunj@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=turtle.in.the.kernel@gmail.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: 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).