[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH 17/25] spapr: add a sPAPRXive object to the machin

From: David Gibson
Subject: Re: [Qemu-ppc] [PATCH 17/25] spapr: add a sPAPRXive object to the machine
Date: Fri, 1 Dec 2017 15:17:17 +1100
User-agent: Mutt/1.9.1 (2017-09-22)

On Thu, Nov 30, 2017 at 03:38:46PM +0000, Cédric Le Goater wrote:
> >> +    } else {
> >> +        /* XIVE uses the full range of IRQ numbers. The CPU IPIs will
> >> +         * use the range below XICS_IRQ_BASE, which is unused by XICS. */
> >> +        spapr->xive = spapr_xive_create(spapr, XICS_IRQ_BASE + 
> >> +                                        &error_fatal);
> > 
> > XICS_IRQ_BASE == 4096, and XICS_IRQS_SPAPR (which we should rename at
> > some point) == 1024.
> BTW, why XICS_IRQ_BASE == 4096 ? I could not find a reason for
> this offset.

It's basically arbitrary.  Possible I copied the value used in
practice on a PowerVM system of the time, but I don't recall for sure.

> > So we have a total irq space of 5k, which is a bit odd.  I'd be ok
> > with rounding it out to 8k for newer machines if that's useful.
> ok. and using a machine class value to maintain compatibility. That 
> would be useful if we allocate more PHBs. 
> > Sparse allocations in there might make life easier for getting
> > consistent irq numbers without an "allocator" per se (because we can
> > use different regions for VIO, PCI intx, MSI, etc. etc.).
> So, do you think we should modify the IRQ allocator routines to be 
> able to segment the IRQ number space and let devices specify the
> range they want to use ?

No, I'm suggesting *eliminating* the IRQ allocator routines (except
for backwards compat) and having devices "just know" their irq numbers
based on their own device number and the portion of the overall irq
space they're supposed to live in.

PCI MSI is an exception, obviously, it will need some sort of runtime

> That would be useful for the PHB LSIs. The starting IRQ for the PHB
> could be aligned on some value depending on the PHB index, first 
> would come the LSI interrupts and then the MSIs which are allocated 
> later on by the guest. We would have predictable values.
> Thanks,
> C. 

David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]