>-----Original Message-----
>From: Gregory Haskins [mailto:[EMAIL PROTECTED]
>Sent: 2007年6月5日 1:23
>To: Dong, Eddie; kvm-devel@lists.sourceforge.net
>Subject: RE: [kvm-devel] [PATCH 3/9] KVM: Add irqdevice object
>
>>>> "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.
Then you will push the extint back to Qemu ? BTW, PIC is not in
yet, and I see the patch didn't do push for extirq.
>
>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.
This is what I say. Push back an irq cause not only priority issue,
but actually this irq is already blocked since ISR and TPR are all
updated now. A higher irq definitely will happen too like you observed too.
WHat I am proposing is to split IDT_VECTORING from APIC logic,do it in irq
injecting logic.
>
>
>> 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.
If a guest OS *did* enable both PIC & APIC for a irq, both in the simplified
approach (Xen) and V09 has same effect: exitirq get the priority and get
injected. (BTW SDM doesn't explicitly say which one has priority).
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
