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 <[email protected]> > >>> > >>> 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
signature.asc
Description: PGP signature
