>>> "Dong, Eddie" <[EMAIL PROTECTED]> 06/04/07 3:13 AM >>>
>Greg:
> Can you explain a bit why we need to distinguish
> kvm_irqpin_extint from kvm_irqpin_localint?
They are both "vectored interrupts", but localint means "I have the vector" and
extint means "someone else has the vector". They are closely analogous to the
LAPICs notion of FIXED and EXTINT interrupts respectfully. The difference is I
named them more generally so that it would apply equally to PICs of other types
besides APICs (for abstraction purposes).
> I saw latest V09 has hole here such as handle_exception due to
> IRQ inject fail. I.e. IDT_VECTORING_INFO_FIELD only push localint back,
> but no extint.
Actually, I don't think this is really a hole. Both interrupts are of the same
injection-class and both can be equally deferred. As explained earlier, the
only difference between them is the source of the vectoring data. If an
injection operation fails (regardless of original pin type), we push the vector
into our irq.deferred queue and use it next time.
One problem that I *can* see is related to inadvertent reprioritization based
on how irq.deferred gets grossly classified as a localint. The deferred vector
should be the highest priority interrupt in the system, since it technically
was already dispatched. However, today (in v9 and earlier) new extint or NMIs
would be incorrectly prioritized over irq.deferred. I doubt this would happen
very often (if ever) and I doubt it would cause to many problems if it did.
However, the fix should be pretty easy: there should probably be something like
an irqpin_deferred as the highest priority pin in the system instead of
overloading deferred on localint.
> In Xen, when we implementing APIC patch, we simplify it by
>limiting a single IRQ can either be passed by PIC or APIC, we never
>handle the combination of both PIC and APIC servicing them in same time.
>I.e. If APIC is taking the IRQ, PIC must already mask the pin. That
>works fine so far. I am just wondering if we should start from simple
>model and improve later if we find problem. Same for NMI/SMI handling.
With all due respect, I don't know if I would agree that that approach is
either simpler or superior. Both Xen and QEMU play games with the model w.r.t.
APIC vs PIC interactions, and to date, I don't think either one has got it
quite right. I think they both got it "close enough" to work to some degree
(partially by luck), but its also (IMHO) a hacky way to do it. What I tried to
do was stay truer to the logical model of the ISA architecture as presented by
Bochs/QEMU. So, yes, its true that typically a guest would never enable both
interrupts in the PIC and the APIC. However, if they *did*, my model would
work identically to the way real hardware would work. The others would
mis-emulate this.
As a similar example, consider how LINT0 handling is done today (in QEMU
anyway, but I believe Xen is similar). The patch you made to QEMU a few weeks
ago was definitely a step in the right direction. However, QEMU still has
LINT0 mis-emulation bugs and they are non-trivial to fix with the general model
that QEMU uses. I believe Xen follows a similar model and thus suffers from
the same limitations (I apologize if this has been fixed recently...I haven't
been tracking the Xen code). With the in-kernel patchset, LINT handling
follows hardware once again, and it just works. To see an example of this,
boot a linux kernel with nmi_watchdog enabled. QEMU mis-emulates the NMI
timer, in-kernel-APIC does not.
So that being said: I did it this way because a) it was pretty straight forward
and b) all the corner cases are covered. I don't think all that logic of "if
(apic.enabled && apic.lint0 == EXTINT)" are simpler, especially by the time you
fix all the latent bugs that are created with that model.
> BTW, I am not sure if we should have this abstract now, the irq
> handling path is quit tricky when we do that in Xen time.
Dont forget: one of the primary motivations for the abstraction was to support
backwards compatibility. By having the irq-device abstracted, I can support
old userspace with QEMU APIC emulation quite easily. This is a requirement.
Regards,
-Greg
-------------------------------------------------------------------------
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
