qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
Date: Wed, 30 May 2012 19:17:38 +0300

On Wed, May 30, 2012 at 05:47:45PM +0200, Jan Kiszka wrote:
> On 2012-05-30 16:59, Michael S. Tsirkin wrote:
> > On Wed, May 30, 2012 at 04:46:14PM +0200, Jan Kiszka wrote:
> >> On 2012-05-30 16:42, Michael S. Tsirkin wrote:
> >>> On Wed, May 30, 2012 at 04:38:25PM +0200, Jan Kiszka wrote:
> >>>> On 2012-05-30 15:34, Michael S. Tsirkin wrote:
> >>>>> Below's as far as I got - hopefully this
> >>>>> explains what I had in mind: for deep hierarchies
> >>>>> this will save a bus scan so I think this makes sense
> >>>>> even in the absense of kvm irqchip.
> >>>>>
> >>>>> Warning: completely untested and known to be incomplete.
> >>>>> Please judge whether this is going in a direction that
> >>>>> is helpful for your efforts. If you respond in the positive,
> >>>>> I hope to be able to get back to this next week.
> >>>>
> >>>> We need to
> >>>>  - account for polarity changes along the route
> >>>>  - get rid of irq_count as it is no longer updated in the fast path,
> >>>>    thus useless on routing updates
> >>>
> >>> I'll need to consider this more to understand what you mean here.
> >>
> >> If, e.g., the host bridge is configured to flip the polarity of some
> >> interrupt on delivery, the fast path must be able to explore this in
> >> order to do the same.
> > 
> > This can be solved incrementally I think - handle polarity
> > change like mapping change, no?
> 
> Both belong together if we want to do it generically, IMHO.

So irq_polarity callback like we have for map_irq ATM?  But at least pci
bridges never do this flip.  Maybe this is the property of the interrupt
controller after all?

> > 
> >> Then you may want to have a look at how irq_count is maintained and when
> >> it is used.
> > 
> > In my patch it simply there to OR irq levels of all devices
> > connected to a specific pin.
> 
> I think what we want is to avoid any walks and intermediate state
> updates for all IRQ deliveries.

Well the bus is not an intermediate state ATM as piix
only has a bit per IRQ so it can't OR devices together.
So you want to move the counter over to piix?

> That would be beneficial for any user,
> not just device assignment. It would basically make the special case the
> normal one, reducing code complexity. As there are still some problems
> to solve for this, I'm just unsure if this step goes in the right
> direction and will be reusable.
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux



reply via email to

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