From: David Gibson <david@gibson.dropbear.id.au>
To: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, aik@ozlabs.ru,
mahesh@linux.vnet.ibm.com, benh@au1.ibm.com, paulus@samba.org,
sam.bobroff@au1.ibm.com
Subject: Re: [Qemu-devel] [PATCH v5 1/6] ppc: spapr: Register and handle HCALL to receive updated RTAS region
Date: Fri, 29 Sep 2017 16:17:35 +1000 [thread overview]
Message-ID: <20170929061735.GD7712@umbus.fritz.box> (raw)
In-Reply-To: <150659505839.25889.2018054058894535368.stgit@aravinda>
[-- Attachment #1: Type: text/plain, Size: 4370 bytes --]
On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote:
> Receive updates from SLOF about the updated rtas-base.
> A separate patch for SLOF [1] (commit f9a60de3) adds
> functionality to invoke a private HCALL whenever OS
> issues instantiate-rtas with a new rtas-base.
>
> This is required as QEMU needs to know the updated rtas-base
> as it allocates error reporting structure in RTAS space upon
> a machine check exception.
>
> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120386.html
>
> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Ao I acked this earlier, but I've now realized there might be some
connection between this and discussions taking place elsewhere about
qemu not knowing what SLOF does with the device tree.
At what point will SLOF call the UPDATE_RTAS hcall? I'm guessing at
the time of instantiate-rtas, is that right?
Does SLOF put the RTAS blob address in its internal device tree, or
does it only pass it to the guest via the return parameters from
instantiate-rtas?
> ---
> hw/ppc/spapr.c | 11 +++++++++++
> hw/ppc/spapr_hcall.c | 8 ++++++++
> include/hw/ppc/spapr.h | 4 +++-
> 3 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index ff87f15..5deae30 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1675,6 +1675,16 @@ static const VMStateDescription vmstate_spapr_patb_entry = {
> },
> };
>
> +static const VMStateDescription vmstate_spapr_rtas_addr = {
> + .name = "spapr_rtas_addr",
> + .version_id = 1,
> + .minimum_version_id = 1,
> + .fields = (VMStateField[]) {
> + VMSTATE_UINT64(rtas_addr, sPAPRMachineState),
> + VMSTATE_END_OF_LIST()
> + },
> +};
> +
> static const VMStateDescription vmstate_spapr = {
> .name = "spapr",
> .version_id = 3,
> @@ -1694,6 +1704,7 @@ static const VMStateDescription vmstate_spapr = {
> &vmstate_spapr_ov5_cas,
> &vmstate_spapr_patb_entry,
> &vmstate_spapr_pending_events,
> + &vmstate_spapr_rtas_addr,
> NULL
> }
> };
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 8d72bb7..c15a93c 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1088,6 +1088,13 @@ static target_ulong h_rtas(PowerPCCPU *cpu, sPAPRMachineState *spapr,
> nret, rtas_r3 + 12 + 4*nargs);
> }
>
> +static target_ulong h_rtas_update(PowerPCCPU *cpu, sPAPRMachineState *spapr,
> + target_ulong opcode, target_ulong *args)
> +{
> + spapr->rtas_addr = args[0];
> + return 0;
> +}
> +
> static target_ulong h_logical_load(PowerPCCPU *cpu, sPAPRMachineState *spapr,
> target_ulong opcode, target_ulong *args)
> {
> @@ -1750,6 +1757,7 @@ static void hypercall_register_types(void)
>
> /* qemu/KVM-PPC specific hcalls */
> spapr_register_hypercall(KVMPPC_H_RTAS, h_rtas);
> + spapr_register_hypercall(KVMPPC_H_RTAS_UPDATE, h_rtas_update);
>
> /* ibm,client-architecture-support support */
> spapr_register_hypercall(KVMPPC_H_CAS, h_client_architecture_support);
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index c1b365f..b395aa7 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -90,6 +90,7 @@ struct sPAPRMachineState {
>
> hwaddr rma_size;
> int vrma_adjust;
> + hwaddr rtas_addr;
> ssize_t rtas_size;
> void *rtas_blob;
> long kernel_size;
> @@ -400,7 +401,8 @@ struct sPAPRMachineState {
> #define KVMPPC_H_LOGICAL_MEMOP (KVMPPC_HCALL_BASE + 0x1)
> /* Client Architecture support */
> #define KVMPPC_H_CAS (KVMPPC_HCALL_BASE + 0x2)
> -#define KVMPPC_HCALL_MAX KVMPPC_H_CAS
> +#define KVMPPC_H_RTAS_UPDATE (KVMPPC_HCALL_BASE + 0x3)
> +#define KVMPPC_HCALL_MAX KVMPPC_H_RTAS_UPDATE
>
> typedef struct sPAPRDeviceTreeUpdateHeader {
> uint32_t version_id;
>
--
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 --]
next prev parent reply other threads:[~2017-09-29 6:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-28 10:37 [Qemu-devel] [PATCH v5 0/6] target-ppc/spapr: Add FWNMI support in QEMU for PowerKVM guests Aravinda Prasad
2017-09-28 10:37 ` [Qemu-devel] [PATCH v5 1/6] ppc: spapr: Register and handle HCALL to receive updated RTAS region Aravinda Prasad
2017-09-29 6:17 ` David Gibson [this message]
2017-09-29 11:52 ` [Qemu-devel] [Qemu-ppc] " Nikunj A Dadhania
2017-10-02 3:02 ` Alexey Kardashevskiy
2017-10-03 6:07 ` David Gibson
2017-10-03 9:12 ` Alexey Kardashevskiy
2017-10-04 3:32 ` Alexey Kardashevskiy
2017-10-04 5:55 ` David Gibson
2017-10-03 5:56 ` [Qemu-devel] " Aravinda Prasad
2017-09-28 10:37 ` [Qemu-devel] [PATCH v5 2/6] ppc: spapr: Handle "ibm, nmi-register" and "ibm, nmi-interlock" RTAS calls Aravinda Prasad
2017-09-29 6:49 ` David Gibson
2017-10-03 5:51 ` Aravinda Prasad
2017-10-03 6:09 ` David Gibson
2017-09-28 10:38 ` [Qemu-devel] [PATCH v5 3/6] Wrapper function to wait on condition for the main loop mutex Aravinda Prasad
2017-09-28 10:38 ` [Qemu-devel] [PATCH v5 4/6] target/ppc: Handle NMI guest exit Aravinda Prasad
2017-10-04 1:29 ` David Gibson
2017-10-08 8:59 ` Aravinda Prasad
2017-10-08 23:48 ` David Gibson
2017-09-28 10:38 ` [Qemu-devel] [PATCH v5 5/6] ppc: spapr: Enable FWNMI capability Aravinda Prasad
2017-10-04 1:34 ` David Gibson
2017-10-08 8:26 ` Aravinda Prasad
2017-10-08 23:43 ` David Gibson
2017-09-28 10:38 ` [Qemu-devel] [PATCH v5 6/6] migration: Block migration while handling machine check Aravinda Prasad
2017-10-04 1:39 ` David Gibson
2017-10-08 8:07 ` Aravinda Prasad
2017-09-28 10:53 ` [Qemu-devel] [PATCH v5 0/6] target-ppc/spapr: Add FWNMI support in QEMU for PowerKVM guests no-reply
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=20170929061735.GD7712@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=aik@ozlabs.ru \
--cc=aravinda@linux.vnet.ibm.com \
--cc=benh@au1.ibm.com \
--cc=mahesh@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=sam.bobroff@au1.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: 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).