From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Date: Thu, 10 Feb 2011 13:23:57 +0100 Message-ID: <4D53D8DD.50305@codemonkey.ws> References: <20110208155557.GM6198@x200.localdomain> <4D51B1C9.3080507@codemonkey.ws> <4D526D0D.9020507@codemonkey.ws> <4D52A86A.1030407@codemonkey.ws> <4D52F20A.7070009@codemonkey.ws> <4D539800.3070802@codemonkey.ws> <4D53A39D.8000108@codemonkey.ws> <4D53BA43.2000708@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Blue Swirl , Chris Wright , Markus Armbruster , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Peter Maydell Return-path: Received: from mail-fx0-f46.google.com ([209.85.161.46]:49323 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751111Ab1BJMYC (ORCPT ); Thu, 10 Feb 2011 07:24:02 -0500 Received: by fxm20 with SMTP id 20so1411542fxm.19 for ; Thu, 10 Feb 2011 04:24:00 -0800 (PST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 02/10/2011 11:38 AM, Peter Maydell wrote: > On 10 February 2011 10:13, Anthony Liguori wrote: > >> On 02/10/2011 10:04 AM, Peter Maydell wrote: >> >>> On 10 February 2011 08:36, Anthony Liguori 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 > >