Re: [PATCH 3/8] KVM: Handle device assignment to guests

[Avi Kivity <avi@qumranet.com>]

Ben-Ami Yassour wrote:
>>>>> +
>>>>> +/* FIXME: Implement the OR logic needed to make shared interrupts
>>>>> on + * this line behave properly + */
>>>>>
>>>>>       
>>>>>           
>>>> Isn't this a showstopper?  There is no easy way for a user to avoid
>>>> sharing, especially as we have only three pci irqs at present.
>>>>         
> What do you mean by only 3 (for passthrough we use whatever interrupt
> the host is using for that device)?
>
>   

There are two issue:
- shared host interrupts
- shared guest interrupts

For shared host interrupts, I don't think there's a cost-effective 
solution, especially as hosts are transitioning to MSI.  But the problem 
the comment describes is shared guest interrupts, where the assigned 
device's interrupt is shared with another device (assigned or virtual).

And currently we only have three shareable interrupts: 5, 10, and 11.

See qemu's pci_set_irq() for the logic used to share interrupts.
>>>>     
>>>>         
>>> Currently it's not easy to avoid sharing. I think we can support MSI for
>>> assgined device to solve sharing problem. 
>>>   
>>>       
>> MSI is definitely the right direction, but we also need to support
>> the 
>> OR logic for guests that do not support MSI.
>>
>>     
>
> The main problems that I am ware of with shared interrupt are as
> follows:
>
> 1. Protection
> A bad guest can keep the interrupt line up, and if its shared then it
> interferes with other devices that might not be assigned to this guest.
>
> 2. Performance
> The current implementation disables the irq when the interrupt is
> received on the host and re-enables it when the guest acks the interrupt
> on the virtual ioapic.
>
> Clearly its not nice to do that when other devices uses the same irq...
>
> When removing the enable-disable of the irq, it causes serious
> performance degradation.
> The throughput goes down from 700 to 400 Mb/sec.
> The number of interrupts per second on the host (from the NIC) is 130000
> (compared to 22200 before).
>
>   

These are all shared host interrupt problems.

> Regardless, I think that the right way to go would be to merge the
> current code (with the non-shared interrupt limitation) and then
> continue to work on additional features like shared interrupts support. 
> Do you agree?
>   

The current code will be incredibly easy to break; all you need is more 
than three pci devices.  I think the sharing code can be easily added 
(as a separate patch); all that's needed is to make sure the API is good.

-- 
error compiling committee.c: too many arguments to function