Gregory Haskins wrote:
> On Fri, 2007-06-08 at 17:59 +0800, Dong, Eddie wrote:
>> 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.
>
> Yeah, as noted earlier...this is a problem that has always existed in
> KVM so we aren't introducing new problems. However, we can lay the
> groundwork to fix it going forward by allowing KVM_ISA_INTERRUPT to
> set AND clear interrupts.
>
>
>>
>> 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);
>> +}
>> +
>
> Hmm...let me look into that.
>
>
>>
>> 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
>> :-(
>
> I see your point, but I am fairly confident we can fix it more
> simply by
> going back to a synchronous model like the original
> try_to_push_interrupts used (it has to wait until irq.pending is
> clear, among other things like RFLAGS.IF=1 and MOV-SS + STI blocking
> = 0.
Not exactly, this is insufficient because a new event (irq) may happen
after you check it in
user level such as a NMI for PMU may happen in Kernel after your check.
>
>>
>> 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?
>
> First, let me note that this only happens in "legacy" mode where the
> APIC is in userspace. As that is a legacy mode, we can't really make
> changes there without breaking backwards compatibility.
>
> Second, the reason why I believe it was done this way is performance.
> Windows would be heavy-exiting to userspace constantly if we used the
> approach you are suggesting.
>
>>
>> 4: Both Qemu & Xen doesn't emulate Remote IRR bit of RTE and works
>> well, hopefully we are ok too.
>
> That is my theory too. No-one else seems to handle Remote IRR
> and there
> are no problems that I am aware of, so we don't do anything
> with it here
> either.
>
>>
>> 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
