All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: aik@ozlabs.ru, alex.williamson@redhat.com, qemu-ppc@nongnu.org,
	qemu-devel@nongnu.org, agraf@suse.de
Subject: Re: [Qemu-devel] [PATCH v18 1/2] sPAPR: Implement EEH RTAS calls
Date: Mon, 16 Feb 2015 12:52:48 +1100	[thread overview]
Message-ID: <20150216015248.GG26645@voom.fritz.box> (raw)
In-Reply-To: <1424042162-12249-2-git-send-email-gwshan@linux.vnet.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 3438 bytes --]

On Mon, Feb 16, 2015 at 10:16:01AM +1100, Gavin Shan wrote:
> The emulation for EEH RTAS requests from guest isn't covered
> by QEMU yet and the patch implements them.
> 
> The patch defines constants used by EEH RTAS calls and adds
> callbacks sPAPRPHBClass::{eeh_set_option, eeh_get_state, eeh_reset,
> eeh_configure}, which are going to be used as follows:
> 
>   * RTAS calls are received in spapr_pci.c, sanity check is done
>     there.
>   * RTAS handlers handle what they can. If there is something it
>     cannot handle and the corresponding sPAPRPHBClass callback is
>     defined, it is called.
>   * Those callbacks are only implemented for VFIO now. They do ioctl()
>     to the IOMMU container fd to complete the calls. Error codes from
>     that ioctl() are transferred back to the guest.
> 
> [aik: defined RTAS tokens for EEH RTAS calls]
> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> ---
>  hw/ppc/spapr_pci.c          | 281 ++++++++++++++++++++++++++++++++++++++++++++
>  include/hw/pci-host/spapr.h |   4 +
>  include/hw/ppc/spapr.h      |  43 ++++++-
>  3 files changed, 326 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> index cebdeb3..29b071d 100644
> --- a/hw/ppc/spapr_pci.c
> +++ b/hw/ppc/spapr_pci.c
> @@ -406,6 +406,268 @@ static void rtas_ibm_query_interrupt_source_number(PowerPCCPU *cpu,
>      rtas_st(rets, 2, 1);/* 0 == level; 1 == edge */
>  }
>  
> +static void rtas_ibm_set_eeh_option(PowerPCCPU *cpu,
> +                                    sPAPREnvironment *spapr,
> +                                    uint32_t token, uint32_t nargs,
> +                                    target_ulong args, uint32_t nret,
> +                                    target_ulong rets)
> +{
> +    sPAPRPHBState *sphb;
> +    sPAPRPHBClass *spc;
> +    uint32_t addr, option;
> +    uint64_t buid;
> +    int ret;
> +
> +    if ((nargs != 4) || (nret != 1)) {
> +        goto param_error_exit;
> +    }
> +
> +    buid = ((uint64_t)rtas_ld(args, 1) << 32) | rtas_ld(args, 2);
> +    addr = rtas_ld(args, 0);
> +    option = rtas_ld(args, 3);
> +
> +    sphb = find_phb(spapr, buid);
> +    if (!sphb) {
> +        goto param_error_exit;
> +    }
> +
> +    spc = SPAPR_PCI_HOST_BRIDGE_GET_CLASS(sphb);
> +    if (!spc->eeh_set_option) {
> +        goto param_error_exit;
> +    }
> +
> +    /*
> +     * The EEH functionality is enabled on basis of PCI device,
> +     * instead of PE. We need check the validity of the PCI
> +     * device address.
> +     */
> +    if (option == RTAS_EEH_ENABLE &&
> +        !find_dev(spapr, buid, addr)) {
> +        goto param_error_exit;
> +    }

You're still breaking your layering by doing checks dependent on the
specific option both here and in the callback.

What I meant by my comments on the previous version was that this
find_dev() test should also move into the eeh_set_option callback.
Obviously that means adding addr into the parameters - but surely if
the addr has any meaning whatsoever, it must be at least potentially
needed by the callback anyway.

Apart from that,

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

-- 
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: Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-02-16  4:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-15 23:16 [Qemu-devel] [PATCH v18 0/2] EEH Support for VFIO Devices Gavin Shan
2015-02-15 23:16 ` [Qemu-devel] [PATCH v18 1/2] sPAPR: Implement EEH RTAS calls Gavin Shan
2015-02-16  1:52   ` David Gibson [this message]
2015-02-16  5:32     ` Gavin Shan
2015-02-18 23:29       ` Gavin Shan
2015-02-19  1:28       ` Michael Roth
2015-02-19 22:50         ` Gavin Shan
2015-02-19 23:40           ` David Gibson
2015-02-20  4:48             ` [Qemu-devel] [Qemu-ppc] " Gavin Shan
2015-02-15 23:16 ` [Qemu-devel] [PATCH v18 2/2] sPAPR: Implement sPAPRPHBClass EEH callbacks Gavin Shan
2015-02-16  2:00   ` 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=20150216015248.GG26645@voom.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=gwshan@linux.vnet.ibm.com \
    --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 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.