On Fri, 2012-07-20 at 10:33 -0600, Alex Williamson wrote:> v6:> > So we're back to just the first two patches, unfortunately the> diffstat got bigger though. The reason for that is that I discovered> we don't do anything on release of an eoifd. We cleanup if the kvm> vm is released, but we're dealing with a constrained resource of irq> source IDs, so I think it's best that we cleanup to make sure those> are returned. To do that we need nearly the same infrastructure as> irqfd, we just only watch for POLLHUP. So while there's more code> here, the structure and function names line up identically to irqfd.> > The other big change here is that KVM_IRQFD returns a token when> setting up a level irqfd. We use this token to associate the eoifd> with the right source. This means we have to put the struct> _source_ids on a list so we can find them. This removes the weird> interaction we were headed to where the eoifd is associated with> the eventfd of the irqfd. There's potentially more flexibility for> the future here too as we might come up with other interfaces that> can return a source ID "key". Perhaps some future KVM_IRQFD will> allow specifying a key for re-attaching. Anyway, the sequence> Michael pointed out where an irqfd is de-assigned then re-assigned> now results in a new key instead of leaving the user wondering if> it re-associates back to the eoifd.> > Also added workqueue flushes on assign since releasing either> object now results in a lazy release via workqueue. This ensures> we re-claim any source IDs we can. Thanks,

FYI, I seem to have found a new locking issue in this version. I'llsend an update when I find it. Thanks,