qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>, Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq
Date: Mon, 21 May 2012 17:35:34 -0300	[thread overview]
Message-ID: <4FBAA716.6000604@siemens.com> (raw)
In-Reply-To: <20120521190546.GA14642@redhat.com>

On 2012-05-21 16:05, Michael S. Tsirkin wrote:
> On Mon, May 21, 2012 at 10:13:47AM -0300, Jan Kiszka wrote:
>> @@ -386,6 +387,14 @@ static void piix3_set_irq(void *opaque, int pirq, int level)
>>      piix3_set_irq_level(piix3, pirq, level);
>>  }
>>  
>> +static int piix3_map_host_irq(void *opaque, int pci_intx)
>> +{
>> +    PIIX3State *piix3 = opaque;
>> +    int host_irq = piix3->dev.config[PIIX_PIRQC + pci_intx];
>> +
>> +    return host_irq < PIIX_NUM_PIC_IRQS ? host_irq : -1;
>> +}
>> +
>>  /* irq routing is changed. so rebuild bitmap */
>>  static void piix3_update_irq_levels(PIIX3State *piix3)
>>  {
> 
> 
> So, instead of special API just for assignment,
> I would like to see map_irq in piix being reworked
> to take dev config into account.
> I think piix is almost unique in this but need to check,

Maybe it is the only host bridge with routing that we have in QEMU right
now, but it is surely not unique (e.g. all later Intel chipsets support
this).

> if not fix other host buses that are programmable.
> PCI bridges are all fixed routing.
> 
> Then we can drop set_irq callback.

set_irq may do more than IRQ routing. It may also flip polarity (see
bonito.c). I guess we need to analyze the requirements of all in-tree
host bridges first.

> 
> Finally all devices can cache the irq#,
> and piix would scan devices behind it
> and update the irq.
> 
> Assignment then just needs a notifier, since
> it owns the device just a pointer in device is
> enough.

I cannot completely follow your ideas here yet. Do you want to pass the
mapping information along the notifier, or why "just ... a notifier"?

> 
> Could you look at doing this please?
> If no I can give it a stub.
> 

Unless we can converge over a final API quickly, I would suggest to base
these refactorings on top of what I propose here. We will have to touch
all host bridges more invasively for this anyway. If you can explain to
me how simple the refactoring can be (but I'm a bit skeptical ;) ), I
could do this, otherwise I would prefer to focus on the device
assignment topic which provide some more nuts.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

  reply	other threads:[~2012-05-21 20:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-21 13:13 [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq Jan Kiszka
2012-05-21 13:15 ` [Qemu-devel] [PATCH 2/2] pci: Add INTx routing notifier Jan Kiszka
2012-05-21 14:13   ` Alex Williamson
2012-05-21 14:10 ` [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq Alex Williamson
2012-05-21 14:36 ` Avi Kivity
2012-05-21 14:47   ` Jan Kiszka
2012-05-21 17:34 ` Michael S. Tsirkin
2012-05-21 18:58   ` Jan Kiszka
2012-05-21 21:04     ` Michael S. Tsirkin
2012-05-21 19:05 ` Michael S. Tsirkin
2012-05-21 20:35   ` Jan Kiszka [this message]
2012-05-21 21:03     ` Michael S. Tsirkin
     [not found] <4FC65910.4030908@siemens.com>
     [not found] ` <20120530174125.GC32721@redhat.com>
     [not found]   ` <4FC65E19.6090203@siemens.com>
     [not found]     ` <4FC65F70.4040501@siemens.com>
     [not found]       ` <20120530182356.GD32721@redhat.com>
     [not found]         ` <20120530182913.GE32721@redhat.com>
     [not found]           ` <20120530185150.GA1546@redhat.com>
     [not found]             ` <4FC66FB1.9050306@siemens.com>
     [not found]               ` <20120530193034.GE1551@redhat.com>
     [not found]                 ` <4FC681B4.3030807@web.de>
     [not found]                   ` <20120530203119.GH1551@redhat.com>
2012-06-01 12:52                     ` Jan Kiszka
2012-06-01 13:27                       ` Michael S. Tsirkin
2012-06-01 13:57                         ` Jan Kiszka
2012-06-01 14:34                           ` Michael S. Tsirkin
2012-06-01 15:15                             ` Jan Kiszka
2012-06-01 15:28                               ` Michael S. Tsirkin
2012-06-01 15:54                                 ` Jan Kiszka
2012-06-01 16:05                                   ` Michael S. Tsirkin
2012-06-01 16:17                                     ` Jan Kiszka
2012-06-01 15:30                               ` Michael S. Tsirkin
2012-06-01 15:59                                 ` Jan Kiszka
2012-06-01 15:26                             ` Michael S. Tsirkin
2012-06-01 13:28                       ` Michael S. Tsirkin
2012-06-01 13:43                         ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FBAA716.6000604@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=alex.williamson@redhat.com \
    --cc=avi@redhat.com \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).