qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] KVM call minutes for Feb 8
Date: Thu, 10 Feb 2011 10:38:53 +0000

On 10 February 2011 10:13, Anthony Liguori <address@hidden> wrote:
> On 02/10/2011 10:04 AM, Peter Maydell wrote:
>>
>> On 10 February 2011 08:36, Anthony Liguori<address@hidden>  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. I don't see the point in modelling a concept that has no
user-visible effects and doesn't actually make the model any
clearer or simpler.

>> In my understanding the "machine" is the thing that says "I need a
>> 926, and an MMC controller at this address, and some UARTS,
>> and..." ie it is the thing that does the "modifying parameters"
>> and "adding different components". So if we'd still be doing that
>> I don't see how we've "got rid of the concept". I guess I'm missing
>> the point somehow.

> A machine today is basically the northbridge, southbridge, plus a bunch of
> default components to make the virtual hardware useful.

This doesn't really correspond to ARM boards I've looked at,
by and large (for instance there's no mention of the word "northbridge"
in the whole 3700 page OMAP3 TRM). PCs may be best modelled
that way, sure, but I don't think you can cram everything into that mould.

>> If you mean that you want machines to be implemented under the
>> hood as a single huge "device" you can only have one of that spans
>> the entire memory map, well I guess that's an implementation
>> detail. But conceptually machines really do exist, and we definitely
>> still want users to be able to say "I want a beagle machine; I want
>> a versatile; I want an n900".

> 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

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]