On Tue, Nov 04, 2008 at 01:57:56PM +0200, Avi Kivity wrote:
> Sheng Yang wrote:
>> Yes, in theory, we got a little trouble, but not that much.
>>
>> The mechanism based on a assumption: every time guest got a interrupt, 
>> it would deassert the interrupt source sooner or later. So we take the 
>> Ack action as the same as deassert the IRQ line here (unmasked the 
>> IRQ).
>>
>> So the biggest known issue is, after guest got the interrupt, rather 
>> than deassert it, guest driver took the advantage of level triggered 
>> interrupt, and just want to deassert after it receive it for e.g. 10 
>> times. Then we would got the trouble. But it's so tricky and we don't 
>> know any device by now take this way yet. Of course they can, so we 
>> also suggest to use a whitelist/blacklist for this approach. But this 
>> should work in most condition.
>>
>> Yeah, it's aggressive, but we think it's reasonable, and tested OK (in 
>> my limited environment). Also I heard that Hyper-V or Vmware did this.
>>
>> Any more concerns? Hope we didn't neglect something.
>>   
>
> Please add a module parameter to disable msi->pciirq conversion in that  
> case.  So if someone runs into trouble, we can try out the alternative.

Yes of course. :)

--
regards
Yang, Sheng

> -- 
> error compiling committee.c: too many arguments to function
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to