[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120814101014.GF11194@redhat.com>
Date: Tue, 14 Aug 2012 13:10:15 +0300
From: Gleb Natapov <gleb@...hat.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Alex Williamson <alex.williamson@...hat.com>, avi@...hat.com,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
jan.kiszka@...mens.com
Subject: Re: [PATCH v7 2/2] kvm: KVM_EOIFD, an eventfd for EOIs
On Tue, Aug 14, 2012 at 01:52:13AM +0300, Michael S. Tsirkin wrote:
> > Using the EOI as a trigger to de-assert and potentially re-assert may be
> > a hack, but it's about as close as we can come to following the behavior
> > of hardware.
> > It's actually quite similar to an apic re-sampling inputs
> > except we don't have a physical line to read and see that it's still
> > asserted. We emulate this by de-asserting it and letting it re-assert
> > if necessary. The emulation to the guest isn't perfect, but it's a lot
> > closer than immediately de-asserting the pin.
> > I think the discussion
> > below describes why I do this versus something that might be even closer
> > to actual hardware.
>
> Sorry I don't understand what "quite similar" means. If deassert on ack
> is "closer" somehow show me some software that needs it.
>
This is incorrect question to ask. The correct one is "is there guest
visible effect" and the answer is yes. If guest reads ioapic irr before
eoi it will incorrectly read zero. Now when we know what is guest visible
effect we can think about whether we can live with it. But it looks like
we can't since this have more serious implications. If interrupt is masked
in ioapic during irq delivery interrupt will be never delivered after unmask.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists