On 2011-10-24 19:23, Michael S. Tsirkin wrote: > On Mon, Oct 24, 2011 at 07:05:08PM +0200, Michael S. Tsirkin wrote: >> On Mon, Oct 24, 2011 at 06:10:28PM +0200, Jan Kiszka wrote: >>> On 2011-10-24 18:05, Michael S. Tsirkin wrote: >>>>> This is what I have in mind: >>>>> - devices set PBA bit if MSI message cannot be sent due to mask (*) >>>>> - core checks&clears PBA bit on unmask, injects message if bit was set >>>>> - devices clear PBA bit if message reason is resolved before unmask (*) >>>> >>>> OK, but practically, when exactly does the device clear PBA? >>> >>> Consider a network adapter that signals messages in a RX ring: If the >>> corresponding vector is masked while the guest empties the ring, I >>> strongly assume that the device is supposed to take back the pending bit >>> in that case so that there is no interrupt inject on a later vector >>> unmask operation. >>> >>> Jan >> >> Do you mean virtio here? Maybe, but I'm also thinking of fully emulated devices. > Do you expect this optimization to give >> a significant performance gain? Hard to asses in general. But I have a silly guest here that obviously masks MSI vectors for each event. This currently not only kicks us into a heavy-weight exit, it also enforces serialization on qemu_global_mutex (while we have the rest already isolated). > > It would also be challenging to implement this in > a race free manner. Clearing on interrupt status read > seems straight-forward. With an in-kernel MSI-X MMIO handler, this race will be naturally unavoidable as there is no more global lock shared between table/PBA accesses and the device model. But, when using atomic bit ops, I don't think that will cause headache. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
