Re: [Qemu-devel] KVM: Windows 64-bit troubles with user space irqchip

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-02-03 11:01, Avi Kivity wrote:
> On 02/03/2011 11:32 AM, Jan Kiszka wrote:
>> On 2011-02-03 09:18, Avi Kivity wrote:
>>>  On 02/02/2011 05:52 PM, Jan Kiszka wrote:
>>>>>>
>>>>>   If there is no problem in the logic of this commit (and I do not see
>>>>>   one yet) then we somewhere miss kicking vcpu when interrupt, that should be
>>>>>   handled, arrives?
>>>>
>>>>  I'm not yet confident about the logic of the kernel patch: mov to cr8 is
>>>>  serializing. If the guest raises the tpr and then signals this with a
>>>>  succeeding, non vm-exiting instruction to the other vcpus, one of those
>>>>  could inject an interrupt with a higher priority than the previous tpr,
>>>>  but a lower one than current tpr. QEMU user space would accept this
>>>>  interrupt - and would likely surprise the guest. Do I miss something?
>>>
>>>  apic_get_interrupt() is only called from the vcpu thread, so it should
>>>  see a correct tpr.
>>>
>>>  The only difference I can see with the patch is that we may issue a
>>>  spurious cpu_interrupt().  But that shouldn't do anything bad, should it?
>>
>> I tested this yesterday, and it doesn't confuse Windows. It actually
>> receives quite a few spurious IRQs in normal operation, w/ or w/o the
>> kernel's tpr optimization.
> 
> I don't see why there should be any spurious interrupts in normal 
> operation.  From the docs, these happen due to an INTA cycle racing with 
> raising the TPR, but in ioapic mode, there shouldn't be any INTA cycles.
> 

I added an instrumentation to the line of apic_get_interrupt that
returns the spurious vector, and it triggered fairly often. Just didn't
examined why this happens even without the tpr optimization.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux