Re: [PATCH] testdev: adjust for ISA irq changes

Jan Kiszka
2011-05-29T15:36:18Z

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

On 2011-05-29 17:26, Avi Kivity wrote:
> On 05/29/2011 06:21 PM, Jan Kiszka wrote:
>> > Suppose our motherboard wired
>> > the PCI links to GSI16-19 (or GSI16-23, as we once wanted before we
>> had
>> > MSI-X)? We'd need an API to access non-ISA interrupt lines.
>> >
>> > So what's the clean fix here? gsi_get_irq()?
>>
>> Maybe. Depends on the requirements of the testdev. If you also want to
>> address PIC and IOAPIC separately or simulate injection from a specific
>> device, we need more logic.
>
> It's impossible to address them separately, the input lines are tied
> together (esp. with kvm irq routing).

That's just how user land implements it ATM. Needs fixing for chipsets
like Q35 that allow the guest to configure the routing. Fortunately, the
KVM kernel interface supports this already.

> I think using GSIs is the right
> thing here.

It really depends on what you want to test with testdev. It's an
artificial thing anyway, so you are free to inject wherever and whatever
you want. But I guess GSI is what was the intention so far.

>
>> We also need a better interface to discover and track legacy IRQ routes
>> for device assignment. Markus is currently collecting requirements for
>> qdev enhancements, and I think generic IRQ manipulation and discovery
>> belongs there.
>
> Possibly. But note that attempting to shoehorn everything into
> bus/device model may not work. Motherboard devices, especially, often
> bypass the bus/device relationship, just because everything is available
> to them on the motherboard, and because hardware designers didn't go to
> software engineering schools but instead do what's necessary to get
> things working. We have to be prepared for exceptions.

Yes, the IRQ tree should probably be independent of the qdev tree. I was
thinking of qdev as the infrastructure that allows to build and maintain
that tree and to associate IRQ pins with qdev devices.

Jan

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