Re: [Qemu-devel] [PATCH 14/19] openpic: convert to qdev

[Scott Wood]

On 12/11/2012 06:56:56 PM, Alexander Graf wrote:
> On 11.12.2012, at 18:47, Scott Wood wrote:
>
> > On 12/11/2012 02:25:31 AM, Alexander Graf wrote:
> >> If we want a pv style generic mpic (for -M e500), let's add such  
> an mpic to the model list and make that one be really generic. But  
> the MPIC in -M mpc8544ds should behave exactly like an mpc8544 mpic.  
> Whenever we fail to do so, we better fix the emulation to be accurate  
> ;)
> >
> > What behaviors would "mpc8544" specify that "fsl mpic v2.0" would  
> not?
>
> I don't know. If you say that mpc8544 == "fsl mpic v2.0" I'm more  
> than happy to rename what we have. Simply calling it "MPIC" was  
> definitely wrong, so I want with the one where I'm actually sure that  
> what I'm implementing is correct, because I have the spec in front of  
> me.
>
> My general approach to this problem would be that we for example get  
> a p4080 board once. Once we get that, we want a p4080 MPIC. Then  
> you'd sit down and model the p4080 MPIC. You realize that it's  
> identical to the mpc8544 MPIC. So you either choose to instantiate an  
> MPC8544 MPIC or you rename the model name to "fsl mpic v2.0".

p4080 would be "fsl mpic v4.2" -- unless you want to model an older  
revision of p4080 in which case it could be v4.0 or v4.1.  Note that  
this example shows that the chip name can be even less specific than  
the block version number.

> If you can assure me today that they will be identical, I'm more than  
> happy to change the name today already :).

"fsl mpic v2.0" describes the MPIC that was integrated into the  
mpc8544, as well as several other chips.  In general you can look at  
versioned SoC blocks as if they were a separate chip, except for  
integration parameters, which should be qdev parameters.  The only  
integration parameters I can think of for MPIC are the number of CPUs  
-- we already deviate from mpc8544 there to allow SMP -- and number of  
interrupt sources, for which we can safely just implement the maximum,  
or make it a qdev parameter if we really care about matching what  
hardware reports in FRR[NIRQ] (this number is actually rather useless  
to software the way Freescale implemented it).

-Scott