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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
