>-----Original Message-----
>From: Gregory Haskins [mailto:[EMAIL PROTECTED]
>Sent: 2007年6月25日 21:43
>To: [EMAIL PROTECTED]
>Cc: Dong, Eddie; kvm-devel@lists.sourceforge.net
>Subject: Re: [kvm-devel] In kernel PIC support: kernel patch
>
>On Sat, 2007-06-23 at 20:41 +0300, Avi Kivity wrote:
>> Dong, Eddie wrote:
>> > 3: IOAPIC position
>> > Though it looks like neutral to have this one in user or kernel
>> > space,
>> > but I'd like to suggest we only support one model.
>Considering future
>> > VT-d
>> > case, hypervisor need to inject an IRQ directly in KVM (still thru
>> > IOAPIC)
>> > without going to user level, so probably moving IOAPIC to
>kernel is good
>> >
>> > in this point.
>> >
>>
>> Even paravirt device drivers will want to inject IRQs via the ioapic
>> (when the guest is not paravirt_ops enabled, like older Linux and
>> Windows).
>
>Note that its probably not a requirement to do so. The IOAPIC
>essentially provides a standard mechanism to map input "irq pins" to
>APIC messages. A pv driver could conceivably call kvm_apicbus_send()
>directly if I knew its vector instead of calling ioapic_setpin() and it
>would achieve the same goal.
Basically we are talking about same thing. calling kvm_apicbus_send or
raise a virtual ioapic pin is basically same. The minor different is who does
the translation from pin to APIC message, device model or IOAPIC model.
Using IOAPIC pin probably makes PV driver writter a little bit easier and
may be reused by other VMM easily in future.
>
>What is nice about using an IOAPIC is that the irq routing can be done
>for you automatically by any ACPI compliant OS. The device just has to
>say "raise my output pin" and the IOAPIC translates that into a vector.
>If you forgo the IOAPIC in favor of direct APIC messages, you have to
>solve the problem of irq-routing a different way.
>
>Note that there is another standard that would allow us to use built-in
>routing without ACPI/IOAPIC: MSI. I know the battle over
>virtual-bus-rendering is still raging w.r.t. to PCI or not-PCI. But I
>will point out that if we do use PCI, setting the PV devices up as MSI
>capable in the config space potentially eliminates the need to
>also wire
>them to an IOAPIC. They will get their vector data from the MSI setup
>and can then send APIC messages directly. (I think there is some
>confusion about how we can do MSI later in this thread...I
>will reply to
>those mails separately)
Yes, all you mentioned here is correct, but it doesn;t impact the
necessity of moving IOAPIC to kernel, see below.
>
>Thoughts?
>
>
>
>> It's probably okay to implement the device side of a block
>> device in qemu, but more difficult for networking. If we have device
>> implementations in the kernel then we'll need an ioapic in
>the kernel.
>
>>
>> Also, if we end up sharing interrupts between the kernel and
>userspace,
>> we'll need the kernel to perform the OR between the level
>specified by
>> the kernel devices and the level specified by userspace.
>
>I not sure I fully understand what you are getting at here. It sounds
>like you are talking about splitting a single IOAPIC into both a user
>and kernel space device? If we do end up needing the IOAPIC in the
No, the IOAPIC is in kernel, but some device such as IDE are in user while
others
are in kernel such as pv NIC.
Due to this, a kernel pv driver will ask for IOAPIC service, so we have to keep
it in kernel, otherwise we have to go back to user when kernel device fires,
which
is very slow.
But, like you mentioned above, if pv device driver uses MSI or APIC message,
it helps, but then 1: we have to implement MSI now, 2: a little bit more
complicated
in writting pv driver.
>kernel and userspace, I would suggest using two IOAPICs (we
>just need to
>update the ACPI tables to say there are two) so that they can operate
>independently. This should be supportable from a virtual system
It can, but a little bit more complicated, and probably unable to live
migration between KVM and Qemu since Qemu only has one IOAPIC.
>infrastructure standpoint, and is much cleaner IMHO. If you were
>talking about a different scenario. please clarify.
>
Thx,eddie
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
