On 2014-07-22 21:06, Michael S. Tsirkin wrote: > On Mon, Jul 21, 2014 at 12:04:22AM +0200, Jan Kiszka wrote: >> On 2014-07-20 23:03, Michael S. Tsirkin wrote: >>> On Sun, Jul 20, 2014 at 11:45:10PM +0200, Jan Kiszka wrote: >>>> On 2014-07-20 21:48, Michael S. Tsirkin wrote: >>>>> On Sat, Jul 19, 2014 at 06:55:48PM +0200, Jan Kiszka wrote: >>>>>> From: Jan Kiszka <jan.kis...@siemens.com> >>>>>> >>>>>> The spec says (and real HW confirms this) that, if the bus master bit >>>>>> is 0, the device will not generate any PCI accesses. MSI and MSI-X >>>>>> messages fall among these. >>>>>> >>>>>> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> >>>>> >>>>> I guess an alternative is for callers to check before >>>>> invoking msi_notify. Please note is this is only option >>>>> when using e.g. irqfd, so this has some advantages. >>>>> Is there a specific device that is affected by this? >>>>> I would expect drivers to disable msi before clearing >>>>> bus master bit ... >>>> >>>> This is about emulating conforming behaviour without touching each and >>>> every device. I stumbled over this while playing with emulated vs. real >>>> Intel HDA. >>> >>> Right so that's my question. >>> How did you hit it? With a custom driver? >> >> So to say: with a hand full lines of code to tickle some MSI event out >> of that device for testing purposes. >> >>> Doesn't regulat driver disable MSI? >> >> Sure. This is not fixing a regular's driver problem. It's a behavioral >> correction for faulty corner cases. >> >> Jan > > OK based on this I think this is not 2.1 material. Agree?
Agree. I'll look into Paolo's suggestion how to model this asap. Jan
signature.asc
Description: OpenPGP digital signature
