Re: [Qemu-devel] [RFC PATCH] PCI: Introduce INTx check & mask API

[Jan Kiszka]

On 2012-05-25 08:26, Alexey Kardashevskiy wrote:
> 25.05.2012 20:43, Jan Kiszka написал:
>> On 2012-05-24 23:47, Alexey Kardashevskiy wrote:
>>> On 25/05/12 12:29, Jan Kiszka wrote:
>>>> On 2012-05-24 22:18, Alexey Kardashevskiy wrote:
>>>>> On 24/05/12 22:02, Jan Kiszka wrote:
>>>>>> On 2012-05-24 04:44, Alexey Kardashevskiy wrote:
>>>>>>> [Found while debugging VFIO on POWER but it is platform independent]
>>>>>>>
>>>>>>> There is a feature in PCI (>=2.3?) to mask/unmask INTx via PCI_COMMAND 
>>>>>>> and
>>>>>>> PCI_STATUS registers.
>>>>>>
>>>>>> Yes, 2.3 introduced this. Masking is done via command register, checking
>>>>>> if the source was the PCI in question via the status register. The
>>>>>> latter is important for supporting IRQ sharing - and that's why we
>>>>>> introduced this masking API to the PCI layer.
>>>>>
>>>>>
>>>>> Is not it just a quite small optimization to not to disable interrupts on 
>>>>> all devices which share
>>>>> the same IRQ but just on those who fired an interrupt? If so, do PCI 
>>>>> devices really often share
>>>>> IRQs? Does not supporting this mean real slowdown on such devices?
>>>>>
>>>>> As far as I understand, everyone who cares about performance uses 
>>>>> MSI/MSIX, no?
>>>>
>>>> Not everyone is blessed with MSI-only PCI devices. From my notebook:
>>>>
>>>> # cat /proc/interrupts
>>>> [...]
>>>>  22: [...] IO-APIC-fasteoi   ehci_hcd:usb1, ehci_hcd:usb2
>>>>
>>>> So, if I want to assign one EHCI controller to a guest, I have to
>>>> disable the other as well. The same can happen quickly if you attach a
>>>> few legacy PCI adapters to a system and want to pass them through.
>>>
>>> Why? vfio-pci receives interrupt, disables it, handles it, enables 
>>> interrupt back. Yes, handling is
>>> a bit longer and includes passing interrupt to QEMU and then to the guest 
>>> (can be optimized to avoid
>>> QEMU) and waiting for EOI notification but this is all the difference.
>>
>> You can disable the complete IRQ line as you cannot predict when the
>> untrusted device driver that VFIO, KVM, or UIO serves will finally
>> decide to silence the IRQ reason in hardware. If you did this, you risk
>> a DoS attack on those other devices.
> 
> 
> Untrusted device still can pull down (or up? do not remember :) )
> hardware INT# line, stop other devices on this line and you cannot do
> anything about it. How does INTx help if the device is that broken?

If the untrusted device truly complies to PCI 2.3, we can stop it from
pulling that line by setting the generic INTx mask bit. That's the whole
reason for this exercise here.

Jan

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