>>> On Wed, Apr 4, 2007 at 12:49 PM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gregory Haskins wrote:
>
>
> Hmm. If the ioapic is in the kernel, then it's a platform- wide resource
> and you would need a vm ioctl. If ioapic emulation is in userspace,
> then the ioapic logic will have decided which cpu is targeted and you
> would issue a vcpu ioctl.
>
Thats exactly in line with my thinking.
>> So that being said, I think the interface between userspace and kernel would
> be no more complex than it is today. I.e. we would just be passing a single
> int via an ioctl.
>
> I think the interface should mirror the hardware interface at the point
> of the "cut". For example, if we keep the ioapic in userspace, the
> interface is ioapic/apic bus messages. If we push the ioapic into the
> kernel, the interface describes the various ioapic pins and how the
> ioapics are connected to each other and to the processors (i.e. the
> topology).
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);
}
In the future, if we have more than one IOAPIC the system can map to the right
unit according to the topology.
>
> Everything should keep working, that is a must. We just need the
> interfaces to follow the hardware faithfully. The issue with the ioapic
> eoi is worrying me performance wise, though; it looks like we need to
> push the ioapic too if we are to have no- compromise performance on
> unmodified OSes.
Not sure if this will make you feel better, but it appears as though both the
QEMU and the in-kernel model that I inherited don't accurately support IOAPIC
EOI already. From that you can infer that there must not be any
level-sensitive interrupts in use today. Since the system seems to only have
the legacy ISA model (which dictates edge triggers, IIRC), this makes sense.
However, if we want to support level triggers in the future, we will have to
address this. I would be uncomfortable designing something that doesn't take
the IOAPIC EOI into account, even if its not immediately used.
>
> For unmodified guests, use the existing pci irq routing. I certainly
> wouldn't want to debug anything else. For modified guests, there's no
> real problem.
Ill take your word for it ;) I spent a few minutes looking through the linux
kernel trying to figure out how to get a hint about a free vector without
assigning one statically in the header files and came up empty handed. Im sure
there is a way (or maybe static is ok?).
>
>>>>
>>>>
>>> Since you need locking anyway, best to use the unlocked versions
>>> (__set_bit()).
>>>
>>
>> Ack. Yes, locking needs to be added. Votes for appropriate mechanism?
> (e.g. spinlock, mutex, etc?)
>>
>>
>
> spin_lock_irq(), as this lock will frequently have to be taken in host
> irq handlers. Need to be extra careful with the locking in
> {vmx,svm}_vcpu_run().
Ack
>> Well, I could just change any occurrence of "pop_irq" with
> kvm_vcpu_irq_read() and any occurrence of push_irq() to
> kvm_vcpu_irq_inject(), but I don't get the impression that this is what you
> were referring to. Could you elaborate?
>>
>
> I meant having a cleanup patch before that pushes irq handling into
> common code, then the apic patch could modify that to call the kernel
> apic code if necessary.
>
Ack
-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
