From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33038) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0X0f-0004Ad-Aw for qemu-devel@nongnu.org; Mon, 15 Dec 2014 09:52:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0X0X-0003oC-Ro for qemu-devel@nongnu.org; Mon, 15 Dec 2014 09:52:29 -0500 Message-ID: <548EF5A1.2040105@suse.de> Date: Mon, 15 Dec 2014 15:52:17 +0100 From: Alexander Graf MIME-Version: 1.0 References: <1418602508-30845-1-git-send-email-gwshan@linux.vnet.ibm.com> <1418602508-30845-3-git-send-email-gwshan@linux.vnet.ibm.com> In-Reply-To: <1418602508-30845-3-git-send-email-gwshan@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v13 2/3] sPAPR: Implement EEH RTAS calls List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gavin Shan , qemu-ppc@nongnu.org Cc: aik@ozlabs.ru, alex.williamson@redhat.com, qemu-devel@nongnu.org On 15.12.14 01:15, Gavin Shan wrote: > The emulation for EEH RTAS requests from guest isn't covered > by QEMU yet and the patch implements them. >=20 > The patch defines constants used by EEH RTAS calls and adds > callback sPAPRPHBClass::eeh_handler, which is going to be used > this way: >=20 > * 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 sPAPRPHBClass::eeh_handler callback is defined, > it is called. > * sPAPRPHBClass::eeh_handler is only implemented for VFIO now. It > does ioctl() to the IOMMU container fd to complete the call. Error > codes from that ioctl() are transferred back to the guest. >=20 > [aik: defined RTAS tokens for EEH RTAS calls] > Signed-off-by: Gavin Shan > --- > hw/ppc/spapr_pci.c | 246 ++++++++++++++++++++++++++++++++++++= ++++++++ > include/hw/pci-host/spapr.h | 7 ++ > include/hw/ppc/spapr.h | 43 +++++++- > 3 files changed, 294 insertions(+), 2 deletions(-) >=20 > diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c > index 3d70efe..3bb1971 100644 > --- a/hw/ppc/spapr_pci.c > +++ b/hw/ppc/spapr_pci.c > @@ -406,6 +406,233 @@ static void rtas_ibm_query_interrupt_source_numbe= r(PowerPCCPU *cpu, > rtas_st(rets, 2, 1);/* 0 =3D=3D level; 1 =3D=3D edge */ > } > =20 > +static int rtas_handle_eeh_request(sPAPREnvironment *spapr, > + uint64_t buid, uint32_t req, uint32= _t opt) > +{ > + sPAPRPHBState *sphb =3D spapr_pci_find_phb(spapr, buid); > + sPAPRPHBClass *info =3D SPAPR_PCI_HOST_BRIDGE_GET_CLASS(sphb); What happens when you try to cast NULL? Could a guest process invoke a host assert() through this and abort the whole VM? > + > + if (!sphb || !info->eeh_handler) { > + return -ENOENT; > + } > + > + return info->eeh_handler(sphb, req, opt); > +} > + > +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) > +{ > + uint32_t addr, option; > + uint64_t buid =3D ((uint64_t)rtas_ld(args, 1) << 32) | rtas_ld(arg= s, 2); > + int ret; > + > + if ((nargs !=3D 4) || (nret !=3D 1)) { > + goto param_error_exit; > + } > + > + addr =3D rtas_ld(args, 0); > + option =3D rtas_ld(args, 3); > + switch (option) { > + case RTAS_EEH_ENABLE: > + if (!spapr_pci_find_dev(spapr, buid, addr)) { > + goto param_error_exit; > + } > + break; > + case RTAS_EEH_DISABLE: > + case RTAS_EEH_THAW_IO: > + case RTAS_EEH_THAW_DMA: So these don't use the addr hint? Alex