linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alexander Graf <agraf@suse.de>
Cc: aik@ozlabs.ru, Gavin Shan <gwshan@linux.vnet.ibm.com>,
	kvm-ppc@vger.kernel.org, alex.williamson@redhat.com,
	qiudayu@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 4/4] powerpc/eeh: Avoid event on passed PE
Date: Wed, 21 May 2014 10:19:04 +1000	[thread overview]
Message-ID: <1400631544.3986.151.camel@pasglop> (raw)
In-Reply-To: <537B5D85.3010305@suse.de>

On Tue, 2014-05-20 at 15:49 +0200, Alexander Graf wrote:
> So how about we just implement this whole thing properly as irqfd? 
> Whether QEMU can actually do anything with the interrupt is a different 
> question - we can leave it be for now. But we could model all the code 
> with the assumption that it should either handle the error itself or 
> trigger and irqfd write.

I don't object to the idea... however this smells of Deja Vu...

You often tend to want to turn something submitted that fills a specific
gap and implements a specific spec/function into some kind of idealized
grand design :-) And that means nothing gets upstream for weeks or monthes
as we churn and churn...

Sometimes it's probably worth it. Here I would argue against it and would
advocate for doing the basic functionality first, as it is used by guests,
and later add the irqfd option. I don't see any emergency here and adding
the irqfd will not cause fundamental design changes:

The "passed" flag (though I'm not fan of the name) is really something
we want in the low level handlers to avoid triggering host side EEH in
various places, regardless of whether we use irqfd or not.

This is totally orthogonal from the mechanism used for notifications.

Even in host, the detection path doesn't always involve interrupts, and
we can detect some things as a result of a host side config space access
for example etc...

So let's keep things nice and separate here. The interrupt notification
is just an "optimization" which will speed up discovery of the error in
*some* cases later on (but adds its own complexity since we have multiple
discovery path in host, so we need to keep track whether we have notified
yet or not etc...) so let's keep it for later.

Cheers,
Ben.

  parent reply	other threads:[~2014-05-21  0:19 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-20  8:30 [PATCH RFCv4 0/4] EEH Support for VFIO PCI device Gavin Shan
2014-05-20  8:30 ` [PATCH 1/4] drivers/vfio: Introduce CONFIG_VFIO_PCI_EEH Gavin Shan
2014-05-20  8:30 ` [PATCH 2/4] powerpc/eeh: Flags for passed device and PE Gavin Shan
2014-05-20  8:30 ` [PATCH 3/4] drivers/vfio: New IOCTL command VFIO_EEH_INFO Gavin Shan
2014-05-20 11:21   ` Alexander Graf
2014-05-20 11:28     ` Alexander Graf
2014-05-20 11:40       ` Gavin Shan
2014-05-20 11:44         ` Alexander Graf
2014-05-20 12:21           ` Gavin Shan
2014-05-20 12:25             ` Alexander Graf
2014-05-20 12:39               ` Gavin Shan
2014-05-21  0:23                 ` Benjamin Herrenschmidt
2014-05-21  4:39                   ` Gavin Shan
2014-05-21  6:23                   ` Alexander Graf
2014-05-21  7:24                     ` Benjamin Herrenschmidt
2014-05-21 10:48                       ` Gavin Shan
2014-05-21  0:21               ` Benjamin Herrenschmidt
2014-05-20  8:30 ` [PATCH 4/4] powerpc/eeh: Avoid event on passed PE Gavin Shan
2014-05-20 11:25   ` Alexander Graf
2014-05-20 11:56     ` Gavin Shan
2014-05-20 12:14       ` Alexander Graf
2014-05-20 12:45         ` Gavin Shan
2014-05-20 13:49           ` Alexander Graf
2014-05-21  0:13             ` Benjamin Herrenschmidt
2014-05-21  6:16               ` Alexander Graf
2014-05-21  0:19             ` Benjamin Herrenschmidt [this message]
2014-05-21  6:20               ` Alexander Graf
2014-05-21  0:12       ` Benjamin Herrenschmidt
2014-05-21  4:41         ` Gavin Shan
2014-06-03  5:54     ` Paul Mackerras
2014-06-03  7:45       ` Alexander Graf
2014-06-03  7:52         ` Benjamin Herrenschmidt

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=1400631544.3986.151.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=gwshan@linux.vnet.ibm.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=qiudayu@linux.vnet.ibm.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).