From: Alex Williamson <alex.williamson@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: lvivier@redhat.com, thuth@redhat.com, mdroth@linux.vnet.ibm.com,
aik@ozlabs.ru, qemu-devel@nongnu.org, gwshan@linux.vnet.ibm.com,
qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH 01/14] vfio: Start adding VFIO/EEH interface
Date: Wed, 23 Sep 2015 20:12:30 -0600 [thread overview]
Message-ID: <1443060750.23936.517.camel@redhat.com> (raw)
In-Reply-To: <20150924011127.GK15944@voom.fritz.box>
On Thu, 2015-09-24 at 11:11 +1000, David Gibson wrote:
> On Wed, Sep 23, 2015 at 11:28:29AM -0600, Alex Williamson wrote:
> > On Sat, 2015-09-19 at 17:18 +1000, David Gibson wrote:
> > > At present the code handling IBM's Enhanced Error Handling (EEH) interface
> > > on VFIO devices operates by bypassing the usual VFIO logic with
> > > vfio_container_ioctl(). That's a poorly designed interface with unclear
> > > semantics about exactly what can be operated on.
> > >
> > > As a first step to cleaning that up, start creating a new VFIO interface
> > > for EEH operations. Because EEH operates in units of a "Partitionable
> > > Endpoint" (PE) - a group of devices that can't be mutually isolated), it
> > > needs to expose host PEs (that is, IOMMU groups) to the guest. This means
> > > EEH needs VFIO concepts exposed that other VFIO users don't.
> > >
> > > At present all EEH ioctl()s in use operate conceptually on a single PE and
> > > take no parameters except the opcode itself. So, expose a vfio_eeh_op()
> > > function to apply a single no-argument operation to a VFIO group.
> > >
> > > At present the kernel VFIO/EEH interface is broken, because it assumes
> > > there is only one VFIO group per container, which is no longer always the
> > > case. So, add logic to detect this case and warn.
> > >
> > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > > ---
> > > hw/vfio/Makefile.objs | 1 +
> > > hw/vfio/eeh.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++
> > > include/hw/vfio/vfio-eeh.h | 42 ++++++++++++++++++++++++++++++
> > > 3 files changed, 107 insertions(+)
> > > create mode 100644 hw/vfio/eeh.c
> > > create mode 100644 include/hw/vfio/vfio-eeh.h
> > >
> > > diff --git a/hw/vfio/Makefile.objs b/hw/vfio/Makefile.objs
> > > index d540c9d..384c702 100644
> > > --- a/hw/vfio/Makefile.objs
> > > +++ b/hw/vfio/Makefile.objs
> > > @@ -3,4 +3,5 @@ obj-$(CONFIG_SOFTMMU) += common.o
> > > obj-$(CONFIG_PCI) += pci.o
> > > obj-$(CONFIG_SOFTMMU) += platform.o
> > > obj-$(CONFIG_SOFTMMU) += calxeda-xgmac.o
> > > +obj-$(CONFIG_PSERIES) += eeh.o
> > > endif
> > > diff --git a/hw/vfio/eeh.c b/hw/vfio/eeh.c
> > > new file mode 100644
> > > index 0000000..35bd06c
> > > --- /dev/null
> > > +++ b/hw/vfio/eeh.c
> > > @@ -0,0 +1,64 @@
> > > +/*
> > > + * EEH (IBM Enhanced Error Handling) functions for VFIO devices
> > > + *
> > > + * Copyright Red Hat, Inc. 2015
> > > + *
> > > + * Authors:
> > > + * David Gibson <dgibson@redhat.com>
> > > + *
> > > + * This program is free software: you can redistribute it and/or
> > > + * modify it under the terms of the GNU General Public License as
> > > + * published by the Free Software Foundation, either version 2 of the
> > > + * License, or (at your option) any later version.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > > + * GNU General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU General Public License
> > > + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> > > + *
> > > + * Based on earlier EEH implementations:
> > > + * Copyright (c) 2011-2014 Alexey Kardashevskiy, IBM Corporation.
> > > + */
> > > +#include <sys/ioctl.h>
> > > +#include <linux/vfio.h>
> > > +
> > > +#include "qemu/error-report.h"
> > > +
> > > +#include "hw/vfio/vfio-common.h"
> > > +#include "hw/vfio/vfio-eeh.h"
> > > +
> > > +int vfio_eeh_op(VFIOGroup *group, uint32_t op)
> > > +{
> > > + VFIOContainer *container = group->container;
> > > + struct vfio_eeh_pe_op pe_op = {
> > > + .argsz = sizeof(pe_op),
> > > + .op = op,
> > > + };
> > > + int ret;
> > > +
> > > + if (!container) {
> > > + error_report("vfio/eeh: EEH_PE_OP 0x%x called on unattached group %d",
> > > + op, group->groupid);
> > > + return -ENODEV;
> > > + }
> > > +
> > > + /* A broken kernel interface means EEH operations can't work
> > > + * correctly if there are multiple groups in a container */
> > > + if ((QLIST_FIRST(&container->group_list) != group)
> > > + || QLIST_NEXT(group, container_next)) {
> > > + error_report("vfio/eeh: EEH_PE_OP 0x%x called on container"
> > > + " with multiple groups", op);
> > > + return -ENOSPC;
> >
> > -EINVAL really seems more appropriate
>
> So, I agree that ENOSPC is a dubious choice, but EINVAL is definitely
> wrong here.
>
> Broad as it is, EINVAL should always indicate that the caller has
> supplied some sort of bad parameter. In this case the parameters are
> just fine, it's just that the kernel is broken so we can't handle that
> case.
>
> Perhaps EBUSY? Since there isn't an ESHOULDWORKBUTDOESNT or EDEVBROKEN.
The caller has supplied a bad parameter, a group that doesn't match the
existing group in the container. If you really object, EPERM? EACCES?
> > > + }
> > > +
> > > + ret = ioctl(container->fd, VFIO_EEH_PE_OP, &pe_op);
> > > + if (ret < 0) {
> > > + error_report("vfio/eeh: EEH_PE_OP 0x%x failed on group %d: %m",
> > > + op, group->groupid);
> > > + }
> > > +
> > > + return ret;
> >
> > Would -errno be more interesting in the failure case?
>
> Oh, yes. Too much kernel work, I'm used to things returning the error
> code.
>
next prev parent reply other threads:[~2015-09-24 2:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-19 7:18 [Qemu-devel] [RFC PATCH 00/14] Allow EEH on "normal" sPAPR PCI host bridge David Gibson
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 01/14] vfio: Start adding VFIO/EEH interface David Gibson
2015-09-23 17:28 ` Alex Williamson
2015-09-24 1:11 ` David Gibson
2015-09-24 2:12 ` Alex Williamson [this message]
2015-09-24 4:09 ` David Gibson
2015-09-24 5:45 ` Thomas Huth
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 02/14] spapr_pci: Switch EEH to vfio_eeh_op() interface David Gibson
2015-09-23 17:28 ` Alex Williamson
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 03/14] spapr_pci: Expose and generalize spapr_phb_check_vfio_group() David Gibson
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 04/14] spapr_pci: Fold spapr_phb_vfio_eeh_configure() into spapr_pci code David Gibson
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 05/14] spapr_pci: Fold spapr_phb_vfio_eeh_reset() " David Gibson
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 06/14] spapr_pci: Fold spapr_phb_vfio_eeh_get_state() " David Gibson
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 07/14] spapr_pci: Fold spapr_phb_vfio_eeh_set_option() " David Gibson
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 08/14] spapr_pci: Fold spapr_phb_vfio_eeh_configure() " David Gibson
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 09/14] vfio: Expose a VFIO PCI device's group for EEH David Gibson
2015-09-23 17:28 ` Alex Williamson
2015-09-24 1:16 ` David Gibson
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 10/14] spapr_pci: Track guest Partitionable Endpoints David Gibson
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 11/14] spapr_pci: Allow EEH on spapr-pci-host-bridge David Gibson
2015-09-23 17:28 ` Alex Williamson
2015-09-24 1:49 ` David Gibson
2015-09-24 2:19 ` Alex Williamson
2015-09-24 4:11 ` David Gibson
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 12/14] spapr_pci: (Mostly) remove spapr-pci-vfio-host-bridge David Gibson
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 13/14] spapr_pci: Remove finish_realize hook David Gibson
2015-09-19 7:18 ` [Qemu-devel] [RFC PATCH 14/14] vfio: Eliminate vfio_container_ioctl() 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=1443060750.23936.517.camel@redhat.com \
--to=alex.williamson@redhat.com \
--cc=aik@ozlabs.ru \
--cc=david@gibson.dropbear.id.au \
--cc=gwshan@linux.vnet.ibm.com \
--cc=lvivier@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=thuth@redhat.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).