On 06/28/2009 03:59 PM, Gregory Haskins wrote:
I agree that we want POLLHUP support, it's better than holding on to
the eventfd. But I think we can make it even cleaner by merging it
with deassign. Basically, when we get POLLHUP, we launch a slow_work
(or something) that does a regular deassign. That slow_work can grab
a ref to the vm, so we don't race with the VM disappearing.
But given that the current slow_work does almost nothing, I'm not sure
it's worth it.
Yeah, and also note that the algorithm to unhook each side is not quite
symmetrical. I think I've captured all the common parts (in things like
irqfd_deactivate(), etc). A minor change in kvm_irqfd_release() could
technically use a deferred job to release instead of doing it inline,
but I do not think it buys us very much to do so (as you pointed out,
the defered part is actually fairly simple). The important parts of the
protocol lie outside of the work we can do in the work-item anyway.
Is the case of deassign vs POLLHUP covered?
Reusing deassign in POLLHUP at least makes it easy to verify that it is.
--
error compiling committee.c: too many arguments to function
--
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
