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 16:46:14 +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: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.

Then you may want to have a look at how irq_count is maintained and when
it is used.

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