Re: [Qemu-ppc] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure

[Cédric Le Goater]

On 09/06/2016 11:45 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2016-09-06 at 16:42 +0200, Cédric Le Goater wrote:
>>> Alternatively.. it might be simpler to just drop the SCOM as a
>>> separate device.  I think you could just hang the scom bus directly
>>> off the chip object.  IIUC the scom is basically the only chip-
>> level
>>> control mechanism, so this does make a certain amount of sense.
>>
>> yes. I am exposing more and more stuff of the chip object under the 
>> xscom object so we should merge them. I agree. We will still need 
>> some XScomDevice of some sort.
> 
> What you can do is split it this way which matches the HW:
> 
>  - The chip object is the XSCOM parent, it owns the XSCOM bus,
> and expose functions (methods) to read/write XSCOMs. WE could rename
> XSCOM to "PIB" or "PCB" which is the real name of the bus ;-) But that
> might confuse things more than help .

Well, "Pervasive" should be mentioned somewhere, it is central to
PowerPC architecture. I will add a comment for the "PIB" (Pervasive 
Interconnect Bus) aka XSCOM bus

>  - A separate ADU object on each chip that is a SysDevice and does the
> MMIO bridge to XSCOM. It decodes the MMIO range for that chip and calls
> the above accessors.

ok. So the ADU is the address space holder. 

> That makes it easy to generate XSCOMs using different mechanisms if we
> wish to do so, which could come in handy, such as monitor commands, 

yes, that will be helpful to trigger some behavior from the command
line.

> or if we ever do cosimulation with a separate BMC, a simulated FSI, 
> all by just calling the first object's methods.

The cosimulation is not a long term goal, for the ipmi-bt part. But 
yes, having a more complete model would be excellent.

Cheers,

C.