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: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
Date: Wed, 30 May 2012 17:47:45 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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.

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