[Top][All Lists]

[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 17:59:51 +0300

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?

> 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.

> > 
> >> So it's a bit more complicated and requires a some broader refactorings.
> > 
> > Is this one good as a first step then?
> > If not I'll drop it for now.
> I think we can't reliably implement this fast path delivery without
> solving the above issues, so we can't do it stepwise, at least not with
> this as first one.
> 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]