On Thu, Jul 19, 2012 at 12:21:07PM +0300, Gleb Natapov wrote: > On Thu, Jul 19, 2012 at 12:17:19PM +0300, Michael S. Tsirkin wrote: > > On Thu, Jul 19, 2012 at 10:53:37AM +0300, Gleb Natapov wrote: > > > On Thu, Jul 19, 2012 at 01:11:53AM +0300, Michael S. Tsirkin wrote: > > > > This creates a way to detect when kvm_set_irq(...,0) was run > > > > twice with the same source id by returning 0 in this case. > > > > > > > > Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx> > > > > --- > > > > > > > > This is on top of my bugfix patch. Uncompiled and untested. Alex, I > > > > think something like this patch will make it possible for you to simply > > > > do > > > > if (kvm_set_irq(...., 0)) > > > > eventfd_signal() > > > > > > > Why caller can't track line state? > > > > Why duplicate information? As we are finding it's not trivial to keep > > the two in sync. Think about migration etc ... > > > We do not migrate irq_states. The caller already have to have enough > information to recreate its state and it should migrate the info, so why > should we go all the way down the call chain to find something that is > already known? Hmm it's an interesting point. Looks like irqfds for level lose state across migration. Of course Alex wants to use them for assignment which currently disables migration, but we are talking about a generic API, so it's a problem that there's no way to retrieve the state. Also migration is only one example. Duplicated state is generally nasty. We would need extra locking too which is not nice. > -- > Gleb. -- 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
