Re: [Qemu-devel] [PATCH 05/13] pci: Add pci_device_route_intx_to_irq

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2213 bytes --]

On 2012-06-10 17:55, Michael S. Tsirkin wrote:
>>> So if you expect me to merge this work, then either Jan does (1), or
>>> gives up and does (2), or I find some time and do (1), or I fail to do
>>> (1) and get convinced that we need to do (3). Or someone else gets
>>> involved.
>>
>> I still have trouble seeing how (3) is a problem.  The translation of an
>> INTx to an irq is chipset specific.  We need a chipset function to
>> perform that transform.  We don't know how to do this for every chipset
>> in the tree, nor do many of those chipset care at the moment about
>> device assignment.  Jan has created an arrangement where chipsets can
>> easily opt-in to this support.  Aside from asking us to go spend a month
>> digging up specs for every chipset in tree and trying to implement this
>> ourselves, what kind of enhancement to the interface are you looking
>> for?  Thanks,
>>
>> Alex
> 
> Sorry I don't understand what you are talking about.
> It's better to have one way to determine interrupt routing than two.
> It can be done, and IIUC Jan doesn't disagree.
> There are gnarly issues related to migration compatibility
> with old qemu sorrounding the solution which makes Jan think it's too complex,
> but nothing remotely related to digging up any specs.

Caching the host bridge generically means changing all chipsets and,
well, also testing that they still work afterward. As explained before,
I'd really like to avoid doing this in a single step.

And there are still migration issues - as explained based on the PIIX3.
Until it is officially stated that we give up on backward migratability,
it will be quite some effort (ie. lots of additional code) to provide
compatibility on top of generic intx-to-irq routing.

This interface here is surely not the perfect solution. But it is better
than a) hacking device assignment and VFIO into a specific chipset and
b) starting a huge refactoring now. We can surely tweak some aspects of
this approach before merging, e.g. documentation. But lets try to move
forward in small, well testable steps. I really don't see the need for
touching all chipsets and migration formats for this purpose ATM.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]