From: Gavin Shan <gwshan@linux.vnet.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: alex.williamson@redhat.com, qemu-ppc@nongnu.org,
Gavin Shan <gwshan@linux.vnet.ibm.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 1/3] VFIO: Clear stale MSIx table during EEH reset
Date: Mon, 23 Mar 2015 16:25:10 +1100 [thread overview]
Message-ID: <20150323052510.GA9147@shangw> (raw)
In-Reply-To: <20150323050656.GR25043@voom.fritz.box>
On Mon, Mar 23, 2015 at 04:06:56PM +1100, David Gibson wrote:
>On Fri, Mar 20, 2015 at 05:27:29PM +1100, Gavin Shan wrote:
>> On Fri, Mar 20, 2015 at 05:04:01PM +1100, David Gibson wrote:
>> >On Tue, Mar 17, 2015 at 03:31:24AM +1100, Gavin Shan wrote:
>> >> The PCI device MSIx table is cleaned out in hardware after EEH PE
>> >> reset. However, we still hold the stale MSIx entries in QEMU, which
>> >> should be cleared accordingly. Otherwise, we will run into another
>> >> (recursive) EEH error and the PCI devices contained in the PE have
>> >> to be offlined exceptionally.
>> >>
>> >> The patch clears stale MSIx table before EEH PE reset so that MSIx
>> >> table could be restored properly after EEH PE reset.
>> >>
>> >> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>> >> ---
>> >> v2: vfio_container_eeh_event() stub for !CONFIG_PCI and separate
>> >> error message for this function. Dropped vfio_put_group()
>> >> on NULL group
>> >> ---
>> >> hw/vfio/Makefile.objs | 6 +++++-
>> >> hw/vfio/common.c | 7 +++++++
>> >> hw/vfio/pci-stub.c | 17 +++++++++++++++++
>> >> hw/vfio/pci.c | 38 ++++++++++++++++++++++++++++++++++++++
>> >> include/hw/vfio/vfio.h | 2 ++
>> >> 5 files changed, 69 insertions(+), 1 deletion(-)
>> >> create mode 100644 hw/vfio/pci-stub.c
>> >>
>> >> diff --git a/hw/vfio/Makefile.objs b/hw/vfio/Makefile.objs
>> >> index e31f30e..1b8a065 100644
>> >> --- a/hw/vfio/Makefile.objs
>> >> +++ b/hw/vfio/Makefile.objs
>> >> @@ -1,4 +1,8 @@
>> >> ifeq ($(CONFIG_LINUX), y)
>> >> obj-$(CONFIG_SOFTMMU) += common.o
>> >> -obj-$(CONFIG_PCI) += pci.o
>> >> +ifeq ($(CONFIG_PCI), y)
>> >> +obj-y += pci.o
>> >> +else
>> >> +obj-y += pci-stub.o
>> >> +endif
>> >> endif
>> >> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
>> >> index 148eb53..ed07814 100644
>> >> --- a/hw/vfio/common.c
>> >> +++ b/hw/vfio/common.c
>> >> @@ -949,7 +949,14 @@ int vfio_container_ioctl(AddressSpace *as, int32_t groupid,
>> >> switch (req) {
>> >> case VFIO_CHECK_EXTENSION:
>> >> case VFIO_IOMMU_SPAPR_TCE_GET_INFO:
>> >> + break;
>> >> case VFIO_EEH_PE_OP:
>> >> + if (vfio_container_eeh_event(as, groupid, param) != 0) {
>> >
>> >I really dislike the idea of having an arbitrarily complex side effect
>> >from a function whose name suggest's it's just a trivial wrapper
>> >around the ioctl().
>> >
>>
>> Ok. I guess you would like putting the complex in the callers of
>> vfio_container_ioctl().
>
>Well.. maybe. I'd also be happy if helper functions were implemeneted
>which both called the ioctl() and did the other necessary pieces.
>They should just be called something that indicates their full
>function, not a name which suggests they're just an ioctl wrapper.
>
Indeed, vfio_container_ioctl() isn't indicating what the function is doing.
How about renaming it to vfio_container_event_and_ioctl()? I'm always bad
at giving a good function name :)
Thanks,
Gavin
>> All those callers are implemtend in sPAPR
>> platform (spapr_pci_vfio.c). I didn't put the logic there because:
>>
>> - VFIOPCIDevice is invisible to sPAPR platform.
>
>It seems kind of silly that VFIOPCIDevice isn't visible to
>spapr_pci_vfio.c.
>
>> - We can't tell one particular PCI device attached to sPAPRPHBState
>> is the basement of VFIOPCIDevice, or emulated PCI device.
>
>I'm not sure what you mean by that.
>
>
>--
>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-03-23 5:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-16 16:31 [Qemu-devel] [PATCH v2 1/3] VFIO: Clear stale MSIx table during EEH reset Gavin Shan
2015-03-16 16:31 ` [Qemu-devel] [PATCH v2 2/3] VFIO: Disable INTx interrupt on " Gavin Shan
2015-03-17 21:16 ` Alex Williamson
2015-03-18 4:54 ` [Qemu-devel] [Qemu-ppc] " Gavin Shan
2015-03-20 4:01 ` Gavin Shan
2015-03-20 5:57 ` Gavin Shan
2015-03-16 16:31 ` [Qemu-devel] [PATCH v2 3/3] sPAPR: Reenable EEH functionality on reboot Gavin Shan
2015-03-17 21:09 ` [Qemu-devel] [PATCH v2 1/3] VFIO: Clear stale MSIx table during EEH reset Alex Williamson
2015-03-17 23:26 ` Gavin Shan
2015-03-23 5:05 ` Gavin Shan
2015-03-20 6:04 ` David Gibson
2015-03-20 6:27 ` [Qemu-devel] [Qemu-ppc] " Gavin Shan
2015-03-23 5:06 ` David Gibson
2015-03-23 5:25 ` Gavin Shan [this message]
2015-03-24 5:41 ` David Gibson
2015-03-24 6:24 ` Gavin Shan
2015-03-24 6:54 ` David Gibson
2015-03-24 12:53 ` Alex Williamson
2015-03-26 0:53 ` Gavin Shan
2015-03-26 1:10 ` David Gibson
2015-03-26 1:30 ` Gavin Shan
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=20150323052510.GA9147@shangw \
--to=gwshan@linux.vnet.ibm.com \
--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 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).