Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/10/2011 11:38 AM, Peter Maydell wrote:
> On 10 February 2011 10:13, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> On 02/10/2011 10:04 AM, Peter Maydell wrote:
>>      
>>> On 10 February 2011 08:36, Anthony Liguori<anthony@codemonkey.ws>    wrote:
>>>        
>>>> So you would model arm926ej-s as the chipset and then build up the
>>>> machines
>>>> by modifying parameters of the chipset (like the board id) and/or adding
>>>> different components on top of it.
>>>>
>>>>          
>>> Er, ARM926 is the CPU, it's not a chipset. The board ID is definitely
>>> not a property of an ARM926, it's a property of the board (clue is in
>>> the name :-)). I don't think versatile boards have a "chipset" really...
>>>
>>>        
>> As I said, I'm not well versed in the component names in ARM.
>>
>> But that said, an actual processor doesn't connect directly to a bunch of
>> devices.  It almost always go through some chipset and that chipset
>> implements a lot of functionality typically.
>>
>> I think the name of the component I'm trying to refer to PL300 which I
>> believe is the Northbridge used for the Versatile boards.
>>      
> PL300 is just a bus interconnect (so you can connect multiple AXI
> bus masters (cores) to multiple AXI bus slaves (devices)).
> Versatile PB doesn't have anything in the documentation that claims
> to be a Northbridge (PBX does, VExpress doesn't).
>
> This is the system diagram for the Versatile Express:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0447d/I1007683.html
> I don't know what you'd want to claim is a "northbridge" there.
> Basically there's an FPGA with a pile of devices in it,
> and there's a test chip with the core and some other devices in
> it. But from a modelling perspective this is all completely
> irrelevant because regardless of where the hardware designer
> put the devices, they're just devices at a particular point in the
> memory map and with a particular set of interrupt wiring and so
> on.

But something interacts with each processor and dispatches the I/O 
operations in the address space, no?  I can't believe there are 2^32 
address lines coming off of every arm chip that each device connects.

This relationship of how I/O fans out through various devices is 
important because occasionally platforms do weird things during I/O fan 
out like implement an IOMMU.  If we don't model this I/O dispatch model 
within QEMU, then it's extremely difficult to implement things like IOMMUs.

It might be the case that a platform has a chipset that is a pile of 
well isolated devices that are crammed in the same silicon space but 
that otherwise have very well defined interactions with each other.  
This is the exception though, not the rule.

Particularly when looking at the relationship between certain devices on 
the PC (like the role the pckbd plays in address translation), things 
are simply not so idealized in practice.

But if it makes sense for ARM to describe every single platform device 
through a factory interface, that's fine.

Even in this case, you still want to model things like the distinction 
between the UART16650A and the ISA bus bridge for the serial device.  In 
this case, you want to be able to do composition without going through a 
factory.

>> An n900 is a very specific hardware configuration that is best represented
>> by some sort of configuration file vs. something hard coded in QEMU.
>>      
> Yes, that's the whole point -- "machine" == "specific hardware
> configuration".
>
> That's not getting rid of "machine", it's just saying "we should have
> some custom scripting language to define them rather than doing
> them in C". You still want, fundamentally, to be able to say
>    qemu-system-arm -M machinename
>    

No, qemu-system-arm -M /path/to/n900.cfg

But yeah, no disagreement there.  But today, the machine concept in QEMU 
is definitely not a specific hardware configuration.

Regards,

Anthony Liguori

> -- PMM
>
>