From: Gavin Shan <gwshan@linux.vnet.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-devel@nongnu.org, aik@ozlabs.ru, agraf@suse.de,
Gavin Shan <gwshan@linux.vnet.ibm.com>,
alex.williamson@redhat.com, qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v18 1/2] sPAPR: Implement EEH RTAS calls
Date: Mon, 16 Feb 2015 16:32:09 +1100 [thread overview]
Message-ID: <20150216053209.GA8304@shangw> (raw)
In-Reply-To: <20150216015248.GG26645@voom.fritz.box>
On Mon, Feb 16, 2015 at 12:52:48PM +1100, David Gibson wrote:
>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.
>
Ok. Either simply dropping the check here, or moving find_dev() to
sPAPRPHBClass::eeh_set_option() as you suggested. However, there're more
things needed for sPAPRPHBClass::eeh_set_option() to do the check as follows.
David, could you help to confirm which way you prefer?
- Rename find_dev() to spapr_find_pci_dev() and make it public. It will be
called in spapr_pci_vfio.c
- Add one field sPAPRPHBState::spapr to reference the associated sPAPREnvironment,
which is required by spapr_find_pci_dev(). Otherwise, we have to pass sPAPREnvironment
to sPAPRPHBClass::eeh_set_option().
Thanks,
Gavin
>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
next prev parent reply other threads:[~2015-02-16 5:33 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
2015-02-16 5:32 ` Gavin Shan [this message]
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=20150216053209.GA8304@shangw \
--to=gwshan@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=david@gibson.dropbear.id.au \
--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.