[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 06/13] pci: Add INTx routing notifier

From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 06/13] pci: Add INTx routing notifier
Date: Sun, 10 Jun 2012 14:09:20 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

On 2012-06-10 13:39, Michael S. Tsirkin wrote:
> It's OK to use recursion but when done through a callback
> like this it's unreadable.

Isn't the alternative poking into foreign bridge device states for their
secondary buses?

> Also, you need to setup you cache after intx cache has been
> initialized, and you provide no clean way to do that.

Once a PCI device is registered, the INTx route can be queried. So the
device user will call pci_device_route_intx_to_irq once (e.g. in the
device init function which is invoked afterward) to fill its cache and
receive a notification if an update is needed. I do not see why, and
specifically how you could query the route earlier or register a callback.

> One way to fix all this is call the notifier for devices, if set, from
> pci_set_bus_intx_routing.
> Then assume that intx to irq translations can be cached
> even though they aren't now. So you will need to invoke
> pci_set_bus_intx_routing on intx to irq mapping changes,
> and that fires the notifier for free.

pci_set_bus_intx_routing is really only for the initial setup of the
static INTx pin routes. And this happens on
pci_bus_irqs/pci_register_bus, ie. triggered by the host bridge. By that
time, there can't be any notifier listeners - as there are no devices yet.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]