Re: [Qemu-devel] [PATCH v5 13/17] ppc/xics: add a xics_get_cpu_index_by_pir helper

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2876 bytes --]

On Thu, Oct 27, 2016 at 08:05:02PM +0200, Cédric Le Goater wrote:
> On 10/27/2016 05:12 AM, David Gibson wrote:
> > On Tue, Oct 25, 2016 at 12:58:11PM +0200, Cédric Le Goater wrote:
> >> On 10/25/2016 07:36 AM, David Gibson wrote:
> >>> On Sat, Oct 22, 2016 at 11:46:46AM +0200, Cédric Le Goater wrote:
> >>>> We will need this helper to translate the server number of the XIVE
> >>>> (which is a PIR) into an ICPState index number (which is a cpu index).
> >>>>
> >>>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> >>>
> >>> Looks correct as far as it goes, but I wonder if this would be more
> >>> generally useful as a machine level function that searches the cpu
> >>> objects by PIR, returning a pointer.  From that to the cpu_index is
> >>> then trivial.
> >>
> >> Well I guess so. The XICSState argument reduces the scope in case of 
> >> multichip but as this routine is used to initialize the xive registers, 
> >> it does not need to be fast.
> > 
> > Ahh.. I was thinking of the top-level xics object as global, rather
> > than per-chip.
> 
> well, the ICP MMIO region address is linked to the chip but that is all
> for the moment.
>  
> > Except.. does having it per-chip work anyway? The server numbers are 
> > globally unique, aren't they?  
> 
> yes.
>  
> > What happens if you put a server number from one chip as the target 
> > for an ICE on another chip?
> 
> we have the chip number, so we could route ? I haven't gone that far
> in the modeling though. It might be overly complex to do for the purpose.

Right.. yeah, trying to route between XICS objects sounds like a
nightmare.  Really the whole notion of the XICS overall object is that
it represents the whole irq propagation fabric - so it knows about all
the ICPS and all the ICSes and handles the routing between them.

So making the XICS object per-chip I think is a mistake which will
just lead to pain down the track.  See my other mail for a new
suggestion on how to handle this.

> > The xics object is a bit weird, in that it doesn't represent a real
> > device in a sense, but is rather something to co-ordinate global
> > addressing between ICS and ICP units.  Well, I suppose in that sense
> > it represent the interrupt propagation fabric.
> 
> yes. See my other email. I think we can get rid of it and simply use
> a XICSState which links together the ICPs and the ICS of the system. 
> but, let's keep it at the chip level for the moment, it is correct, 
> and see if we need to move it upwards when we work on multichip.

No, I disagree.  I think moving the XICs up a layer will only create
pain later for little benefit now.

-- 
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_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]