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 <c...@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
signature.asc
Description: PGP signature