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 21:29:14 +0300

On Wed, May 30, 2012 at 09:23:56PM +0300, Michael S. Tsirkin wrote:
> On Wed, May 30, 2012 at 07:57:04PM +0200, Jan Kiszka wrote:
> > On 2012-05-30 19:51, Jan Kiszka wrote:
> > >> Well, I'll stop ranting here.  The patch that I sent is not intrusive
> > >> and simply gives you a simple way to implement pci_device_get_host_irq,
> > >> also optimizing emulated devices somewhat.  So if you think you need
> > >> pci_device_get_host_irq I think this is a reasonable way to support
> > >> that.  But if you changed your mind, I don't mind.
> > > 
> > > Sorry, your patch doesn't help me in any way.
> > 
> > [to finish the sentence]
> > 
> > ...as it doesn't handle the final routing step in the host bridge.
> 
> I think you mean the logic in piix3_set_irq_level?
> 
> True. I suggest we make piix3_set_irq_level use the map_irq
> infrastructure somehow:

BTW, can't we simply override map_irq and make it read from
piix3->dev.config[PIIX_PIRQC + pirq]?

The root bus is part of root complex I don't see why
doesn't it output an IRQ# that is directly useful
to feed into the CPU.

> generalize it not to rely on device->bus
> relationship.
> 
> Then something like my patch will solve the problem completely.
> 
> 
> > I
> > still need to look this up and provide that via pci_device_get_host_irq.
> > For that I need the additional callback for host bridges. But I also
> > need to solve the other problems discussed in the past hours. I'm back
> > at the drawing board.
> > 
> > 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]