qemu-devel
[Top][All Lists]
Advanced

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

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


From: Cédric Le Goater
Subject: Re: [Qemu-devel] [PATCH 17/25] spapr: add a sPAPRXive object to the machine
Date: Thu, 30 Nov 2017 15:38:46 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

>> +    } 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 + 
>> XICS_IRQS_SPAPR,
>> +                                        &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. 

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

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. 



reply via email to

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