> Am 21.05.2014 um 02:19 schrieb Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>: > >> 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. EEH handling is your call, but I only see reduced complexity here. I won't nak the current approach though. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
