Hello! > A dedicated IRQ per device for something that is a system wide event > sounds like a waste. I don't understand why a spec change is strictly > required, we only need to support this with the specific virtual bridge > used by QEMU, so I think that a vendor specific capability will do. > Once this works well in the field, a PCI spec ECN might make sense > to standardise the capability. Keeping track of your discussion for some time, decided to jump in... So far, we want to have some kind of mailbox to notify the quest about migration. So what about some dedicated "pci device" for this purpose? Some kind of "migration controller". This is: a) perhaps easier to implement than capability, we don't need to push anything to PCI spec. b) could easily make friendship with Windows, because this means that no bus code has to be touched at all. It would rely only on drivers' ability to communicate with each other (i guess it should be possible in Windows, isn't it?) c) does not need to steal resources (BARs, IRQs, etc) from the actual devices. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
