1: I/F between user/kernel a: Similar with the question in kernel side, current I/F only support an IRQ set notification, we need clear notification too. Especially when guest use IMR to mask the interrupt.
b: following code read irq from PIC which means IRR ->ISR, but kernel may not inject the irq for some reasons. We will have trouble now if a new irq comes in with higher priority. More importantly, pic_read_irq will trigger pic_update_irq and the later one will call kernel_pic_irq_request again, which means recursively call of this API. Please use pic_get_irq instead. +static void kernel_pic_irq_request(void *opaque, int level) +{ + int intno = pic_read_irq(isa_pic); + if (intno > 0) + ext_set_isa_irq(intno); +} + 2: irq service: a: Since the kernel side do_interrupt_request needs to consider both irqs from kernel & user, irqs from userspace by try_push_interrupts may be not serviced (has NMI or higher priority irq). So the semantics of try_push_interrupts should be changed for sharing the user space highest irq info to kernel, then if the processor service this irq, an ack() needs to go back to userspace to move irq from irr to isr. cpu_get_pic_interrupt should be replaced with something like cpu_has_pending_irq in Xen. Sigh, mixed PIC mode will not need more user/kernel interaction :-( 3: Not sure why CR8 needs to be set (and sync) to kernel if APIC is in userspace, rather should we go back to userspace every time when guest read/write CR8? 4: Both Qemu & Xen doesn't emulate Remote IRR bit of RTE and works well, hopefully we are ok too. 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