Hello! One more concern. > Currently we track which IRQ has been mapped to which VGIC list > register and also have to synchronize both. We used to do this > to hold some extra state (for instance the active bit). > It turns out that this extra state in the LRs is no longer needed and > this extra tracking causes some pain later.
Returning to the beginning, can you explain, what kind of pain exactly does it bring? For some reasons here i had to keep all this tracking mechanism, and modified your patchset. I see no significant problems, except memory usage. I have to allocate vgic_irq_lr_map large enough to hold indexes up to 16384, and indexes from dist->nr_irqs to 8192 appear to be not used. Since the map itself is actually used only for piggy-back optimization, it is possible to easily get rid of it using for_each_set_bit(lr, vgic_cpu->lr_used, vgic->nr_lr) iteration instead. The rest of mechanism will work as it is, there's no need to remove the state tracking bitmap and optimization itself. I am currently testing this approach and preparing my alternative patch for upstreaming. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
