>>> On Wed, Apr 4, 2007 at 1:43 PM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gregory Haskins wrote:
>> Agreed. I was thinking that the interface for the "IOAPIC in kernel" model
> would look something like the way the pic_send_irq() function looks, except
> it would also convey BUS/IOAPIC id.
>>
>> so: kvm_inject_interrupt(int bus, int pin, int value);
>>
>> and the "kvmpic" driver would currently translate as bus = 0 (giving us
> IRQ0- 23). E.g.
>>
>> kvmpic_send_irq(int irq, int value)
>> {
>> kvm_inject_interrupt(0, irq, value);
>> }
>>
>
> With appropriate modeling of edge vs level triggered, and translation of
> pin to vector, yes.
I believe we would be ok here. The current code uses a similar model for
edge/level, where edge simply ignores *value*, and level uses non-zero value as
"assert" and 0 as "deassert". As far as the pin/vector mapping, that would be
taken care of by the programming of the IOAPIC by the BIOS/OS.
> pci is level triggered, so maybe the guests just handle the inaccuracy.
>
Good point. I'm not sure how this works today. Perhaps we just get lucky that
nothing checks the IRR in the IOAPIC coupled with a bug in the IOAPIC model
that an APIC message is sent out even if the interrupt is not acknowledged. It
would explain why it works today, anyway. Either way, I would like to get this
modeled "right" this go-round, so the point is moot.
-Greg
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
