On 07/10/15 17:05, Pavel Fedin wrote: > Hello! > > One more concern about the whole thing. I already replied to the previous series, but looks like my > reply was missed. > Your implementation does not care about live migration at all. And there's one fundamental issue > with it. In the redistributor LPIs can be only pending, but in the CPU interface they still can be > active. And they have priorities, therefore they can be preempted, so we can have even more than one > active LPI at once. How to migrate this state? > Here i am trying to prototype this by leaving active interrupts in LRs and allowing the userland to > read/write them. This looks a bit stupid, additionally this will create problems if we are e. g. > migrating from host with 8 LRs to host with 4 LRs, while having 6 active LPIs. Can anybody suggest > better solution? > Technically LPI pending table has unused bits from 0 to 8191, and we have 8192 LPIs, so we could > push active state there, just for migration. Would this be a big violation of specification? It says > nothing about these bits at all. LPIs do not have an active state, at the redistributor or otherwise. M. -- Jazz is not dead. It just smells funny... -- 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
