Re: KVM in-kernel APIC update

["Gregory Haskins" <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>]

>>> On Wed, Apr 4, 2007 at  1:43 PM, in message <4613E3CB.6000904-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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