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. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html