On 02/10/2011 11:38 AM, Peter Maydell wrote:
On 10 February 2011 10:13, Anthony Liguori<anthony@xxxxxxxxxxxxx> wrote:
On 02/10/2011 10:04 AM, Peter Maydell wrote:
On 10 February 2011 08:36, Anthony Liguori<anthony@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
