On Thu, Jul 19, 2012 at 12:33:29PM +0300, Michael S. Tsirkin wrote:
> 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 <m...@redhat.com>
> > > > > ---
> > > > >
> > > > > 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.
>
There is no any problem. Source knows what the line status is.
Furthermore this is a (benign) bug if device calls irq_set with
the same level since it results in needless system calls. Qemu guilty
of it and _that_ should be fixed.
>
> Also migration is only one example. Duplicated state is generally
> nasty. We would need extra locking too which is not nice.
>
I don't know what extra locking you are talking about, but calling
kvm_set_irq() repeatedly with the same level will do a lot of unnecessary
locking in ioapic.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
