qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: "Bharat.Bhushan@freescale.com" <Bharat.Bhushan@freescale.com>,
	Scott Wood <scottwood@freescale.com>,
	qemu-ppc <qemu-ppc@nongnu.org>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 2/2] ppc-e500: implement PCI INTx routing
Date: Thu, 19 Dec 2013 20:32:23 +0200	[thread overview]
Message-ID: <20131219183223.GA15126@redhat.com> (raw)
In-Reply-To: <1126AA7C-B95C-4C37-B249-EA1BE1DB8007@suse.de>

On Thu, Dec 19, 2013 at 05:28:17PM +0100, Alexander Graf wrote:
> 
> On 19.12.2013, at 16:39, Bharat.Bhushan@freescale.com wrote:
> 
> > 
> > 
> >> -----Original Message-----
> >> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> >> Sent: Thursday, December 19, 2013 3:55 AM
> >> To: Alexander Graf
> >> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; QEMU Developers; qemu-ppc; Bhushan
> >> Bharat-R65777
> >> Subject: Re: [PATCH 2/2] ppc-e500: implement PCI INTx routing
> >> 
> >> On Wed, Dec 18, 2013 at 10:53:32PM +0100, Alexander Graf wrote:
> >>> 
> >>> On 28.11.2013, at 07:35, Bharat Bhushan <r65777@freescale.com> wrote:
> >>> 
> >>>> This patch adds pci pin to irq_num routing callback Without this
> >>>> patch we gets below warning
> >>>> 
> >>>> "
> >>>> PCI: Bug - unimplemented PCI INTx routing (e500-pcihost)
> >>>> qemu-system-ppc64: PCI: Bug - unimplemented PCI INTx routing
> >>>> (e500-pcihost) "
> >>>> 
> >>>> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> >>>> ---
> >>>> hw/pci-host/ppce500.c |   20 ++++++++++++++++++--
> >>>> 1 files changed, 18 insertions(+), 2 deletions(-)
> >>>> 
> >>>> diff --git a/hw/pci-host/ppce500.c b/hw/pci-host/ppce500.c index
> >>>> 49bfcc6..3c4cf9e 100644
> >>>> --- a/hw/pci-host/ppce500.c
> >>>> +++ b/hw/pci-host/ppce500.c
> >>>> @@ -88,6 +88,7 @@ struct PPCE500PCIState {
> >>>>    struct pci_inbound pib[PPCE500_PCI_NR_PIBS];
> >>>>    uint32_t gasket_time;
> >>>>    qemu_irq irq[PCI_NUM_PINS];
> >>>> +    uint32_t irq_num[PCI_NUM_PINS];
> >>>>    uint32_t first_slot;
> >>>>    /* mmio maps */
> >>>>    MemoryRegion container;
> >>>> @@ -267,13 +268,26 @@ static int mpc85xx_pci_map_irq(PCIDevice
> >>>> *pci_dev, int pin)
> >>>> 
> >>>> static void mpc85xx_pci_set_irq(void *opaque, int pin, int level) {
> >>>> -    qemu_irq *pic = opaque;
> >>>> +    PPCE500PCIState *s = opaque;
> >>>> +    qemu_irq *pic = s->irq;;
> >>> 
> >>> Double semicolon?
> > 
> > Ok, will correct.
> > 
> >>> 
> >>>> 
> >>>>    pci_debug("%s: PCI irq %d, level:%d\n", __func__, pin , level);
> >>>> 
> >>>>    qemu_set_irq(pic[pin], level);
> >>>> }
> >>>> 
> >>>> +static PCIINTxRoute e500_route_intx_pin_to_irq(void *opaque, int
> >>>> +pin) {
> >>>> +    PCIINTxRoute route;
> >>>> +    PPCE500PCIState *s = opaque;
> >>>> +
> >>>> +    route.mode = PCI_INTX_ENABLED;
> >>>> +    route.irq = s->irq_num[pin];
> >>>> +
> >>>> +    pci_debug("%s: PCI irq-pin = %d, irq_num= %d\n", __func__, pin,
> >> route.irq);
> >>>> +    return route;
> >>>> +}
> >>>> +
> >>>> static const VMStateDescription vmstate_pci_outbound = {
> >>>>    .name = "pci_outbound",
> >>>>    .version_id = 0,
> >>>> @@ -350,12 +364,13 @@ static int e500_pcihost_initfn(SysBusDevice
> >>>> *dev)
> >>>> 
> >>>>    for (i = 0; i < ARRAY_SIZE(s->irq); i++) {
> >>>>        sysbus_init_irq(dev, &s->irq[i]);
> >>>> +        s->irq_num[i] = i + 1;
> >>> 
> >>> Doesn't this duplicate the logic from ppce500_pci_map_irq_slot()? I don't
> >> understand the purpose of this whole exercise to be honest.
> >>> 
> >>> Michael, could you please shed some light on this?
> >>> 
> >>> 
> >>> Alex
> >> 
> >> This is printed by pci_device_route_intx_to_irq - it's used by device assignment
> >> and vfio to figure out which irq does a given pci device drive.
> > 
> > Yes, exactly same reason.
> 
> Is there any way we could get rid of the information duplication? The fact that INTA/B/C/D are mapped to 1,2,3,4 is really a configuration parameter that should only live at a single spot.
> 
> 
> Alex

Yes. In fact I had the idea to only have something like
pci_device_route_intx_to_irq and call it once for all interrupts
and cache that, then use this to send interrupts directly to apic.
Redo this each time routing changes.
I had a patch like this (and I think Jan had one too), but Anthony said
he'll rewrite all interrupt routing using QOM so I dropped it. I'll try
to resurrect it.

  reply	other threads:[~2013-12-19 18:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-28  6:35 [Qemu-devel] [PATCH 0/2] ppc-e500: Adding pci-pin to irq callback and some cleanup Bharat Bhushan
2013-11-28  6:35 ` [Qemu-devel] [PATCH 1/2] ppc-e500: some pci related cleanup Bharat Bhushan
2013-12-18 21:47   ` Alexander Graf
2013-12-19 15:38     ` Bharat.Bhushan
2013-12-19 16:26       ` Alexander Graf
2013-11-28  6:35 ` [Qemu-devel] [PATCH 2/2] ppc-e500: implement PCI INTx routing Bharat Bhushan
2013-12-18 21:53   ` Alexander Graf
2013-12-18 22:24     ` Michael S. Tsirkin
2013-12-19 15:39       ` Bharat.Bhushan
2013-12-19 15:50         ` Michael S. Tsirkin
2013-12-19 15:50           ` Bharat.Bhushan
2013-12-19 16:28         ` Alexander Graf
2013-12-19 18:32           ` Michael S. Tsirkin [this message]
2013-12-20  4:15             ` Bharat.Bhushan
2013-12-20  5:01               ` Michael S. Tsirkin
2013-12-20  5:03   ` Michael S. Tsirkin
  -- strict thread matches above, loose matches on Subject: below --
2013-12-20  9:42 [Qemu-devel] [PATCH 0/2] ppc-e500: Adding pci-pin to irq callback and some cleanup Bharat Bhushan
2013-12-20  9:42 ` [Qemu-devel] [PATCH 2/2] ppc-e500: implement PCI INTx routing Bharat Bhushan
2013-12-20 10:31   ` Alexander Graf
2013-12-20 11:23     ` Bharat.Bhushan
2013-12-22 11:31     ` Michael S. Tsirkin
2013-12-22 14:04       ` Alexander Graf

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=20131219183223.GA15126@redhat.com \
    --to=mst@redhat.com \
    --cc=Bharat.Bhushan@freescale.com \
    --cc=agraf@suse.de \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=scottwood@freescale.com \
    /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).