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:
signature.asc
Description: OpenPGP digital signature
