On Fri, Jun 05, 2009 at 12:02:02PM -0400, Gregory Haskins wrote: > Hi Marcelo! > > Comments about the shutdown path ambiguity are in-line > > Gregory Haskins wrote: > > iosignalfd is a mechanism to register PIO/MMIO regions to trigger an eventfd > > signal when written to by a guest. Host userspace can register any arbitrary > > IO address with a corresponding eventfd and then pass the eventfd to a > > + list_del(&item->list); > > + iosignalfd_item_free(item); > > + } > > + > > + list_del(&group->list); > > + kfree(group); > > +} > > > > So this function is called by the path that executes as we do the last > kvm_put_kvm(). I do not do any careful RCU wrangling here because I > assume that there cannot possibly be any active MMIO/PIO operations at > this time, or the reference would never have dropped. Let me know if > anyone sees any holes in that. > > An alternative approach is to do this similar to how irqfd_release() > works. That is: invoke it from the vmfd release() path instead of the > the kvm object destructor. I currently do not think this is necessary, > but I will throw that out there in case someone likes it better. Gregory, Can't see any problems with it. You might want an upper limit in the number of items per group. -- 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
