From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37898) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnLAi-0004wx-Jo for qemu-devel@nongnu.org; Sun, 01 Dec 2013 23:31:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnLAe-0004kd-Bl for qemu-devel@nongnu.org; Sun, 01 Dec 2013 23:31:48 -0500 Received: from [222.73.24.84] (port=30958 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnLAd-0004jq-BG for qemu-devel@nongnu.org; Sun, 01 Dec 2013 23:31:44 -0500 Message-ID: <529C0CD0.4070002@cn.fujitsu.com> Date: Mon, 02 Dec 2013 12:30:08 +0800 From: Li Guang MIME-Version: 1.0 References: <1385450531-3170-1-git-send-email-lig.fnst@cn.fujitsu.com> <1385450531-3170-4-git-send-email-lig.fnst@cn.fujitsu.com> <5295B9BD.7080101@suse.de> <5295BB1E.1090600@suse.de> <5297E3F1.4060200@cn.fujitsu.com> <5298098C.1040105@suse.de> <52984B0C.9030209@cn.fujitsu.com> <529890CA.9010004@suse.de> In-Reply-To: <529890CA.9010004@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 3/4] hw/arm: add sunxi machine type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Alexey Kardashevskiy , Peter Maydell , Peter Crosthwaite , qemu-devel , Bamvor Jian Zhang Andreas F=E4rber wrote: > Am 29.11.2013 09:06, schrieb Li Guang: > =20 >> Andreas F=E4rber wrote: >> =20 >>> Am 29.11.2013 01:46, schrieb Li Guang: >>> >>> =20 >>>> Andreas F=E4rber wrote: >>>> >>>> =20 >>>>> Am 27.11.2013 10:22, schrieb Andreas F=E4rber: >>>>> >>>>> =20 >>>>>> [...] To my understanding, "sunxi" is the name of a >>>>>> community effort [1] to clean up and upstream the BSP kernels from >>>>>> Allwinner, so it sounds as if this was an attempt to write an >>>>>> emulation >>>>>> for that kernel family while naming everything "sunxi" when in fact >>>>>> the >>>>>> SoCs are called Axx [2] (with A1x =3D sun4i, A2x =3D sun5i, A3x =3D = sun6i >>>>>> but >>>>>> >>>>>> >>>>>> =20 >>>>> My interpolation was incorrect: A10 =3D sun4i, A13 =3D sun5i, A3x =3D= sun6i, >>>>> A20 =3D sun7i >>>>> >>>>> =20 >>>>>> no literal "sunxi" AFAIK) and boards include Cubieboard, Cubieboard2, >>>>>> Cubieboard3/Cubietruck [3] and whatever tablets etc. are out there. >>>>>> (CC'ing Bamvor) >>>>>> >>>>>> That's a lesson we learned from the old "prep" machine: Please name >>>>>> things after real hardware, only then can it later be verified wheth= er >>>>>> the modeling is actually correct or which changes need to be >>>>>> performed. >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>> well, sunxi maybe be representation of Axx series, >>>> but, what's wrong? >>>> >>>> =20 >>> You're modeling too general IMO and thereby you're creating a >>> virtual-only machine (despite parallel efforts by Linaro to introduce >>> mach-virt for that purpose). Please model an actual piece of hardware - >>> SoC and board - and not something random that happens to run with the >>> "sunxi" kernel flavor but will leave us puzzled in the future. Should be >>> pretty easy to avoid. >>> >>> My example was qemu-system-ppc -M prep. Today no one knows what hardware >>> that was supposed to match (possibly none) because there are a number of >>> different PReP based machines from IBM and Motorola out there; switching >>> from OpenHack'Ware to OpenBIOS became difficult because among other >>> things we don't have a device tree dump from a physical machine to >>> compare to, and Herv=E9 thus set out to create new machines such as 40P >>> where we actually know which components the hardware contains rather >>> than which drivers are available in the kernel and happened to have >>> matching QEMU device implementations at the time. >>> A slightly similar problem occurred with -M pc, where we now have an >>> i440fx based one and the new q35 based one. It's easier to abstract >>> commonalities and share code between different devices/machines than >>> turning a generic machine/device into a less generic one, in particular >>> for backwards compatibility for guests, command line and QMP. >>> >>> When the difference between two devices is just a value or an offset, >>> then you can use static properties to set them and have the realize >>> function take them into account. If the composition tree differs >>> significantly or if you want to facilitate reuse, then different types >>> will be needed. Multiple machines can call a shared helper function with >>> some parameter; examples include PC, Versatile Express and DIGIC. >>> >>> >>> =20 >>>> we can't track Axx hardware changes? why? >>>> >>>> =20 >>> Sorry, I don't get that? The Sunxi, Allwinner and Wikipedia pages all >>> document some key differences, in particular Cortex-A8 in A10/A13 vs. >>> Cortex-A7 in A20/A31. Cortex-A7 has MPCore, which drags along some key >>> differences that cannot easily fit in a single SunxiState SoC device. >>> >>> =20 >> right, A10/20... seem have similar devices except CPU >> >> =20 >>> At least from my understanding of Cortex-A9 and Cortex-A15 being much >>> closer than Cortex-A8, that is. For example, you have your own PIC for >>> the Cortex-A8 in this series whereas Cortex-A7 will use ARM's GIC and >>> may be able to reuse the "a15mpcore=5Fpriv" composite device. >>> http://en.wikipedia.org/wiki/List=5Fof=5FARM=5Fmicroprocessor=5Fcores#D= esigned=5Fby=5FARM >>> >>> >>> >>> =20 >>>> and also, this patch-set is also community effort just like >>>> sunxi in linux kernel. >>>> >>>> =20 >>> My whole point is, try to design the model forward from hardware and >>> less backwards from kernel. Whether it's sun4i or A10 is less relevant. >>> Kernels may contain bugs. Hardware doesn't change except for new revs, >>> but definitely not depending on who writes a kernel to run on it. :) >>> >>> >>> =20 >> of course, I am aiming to emulate the real hardware, >> so name is not the problem, right? >> =20 > It is. The x in sunxi appears to be a wildcard. > > Quoting http://linux-sunxi.org/Main=5FPage: > "sunxi represents the family of ARM SoC [...] made by Allwinner Tech." > > The Boxship F20 is named as "sun3i", so it's even ARM9, Cortex-A8 and > Cortex-A7 all within that family. That goes beyond what we can model by > some revision property on a "sunxi" device or with -cpu, and we cannot > today create some deep detail device such as MPCore and wire that up to > containing devices. You can only instantiate devices from the command > line that sit on a bus that supports automatic wiring-up based on device > properties and knowledge of peers on the bus. In particular you cannot > initialize IRQs or map MMIO MemoryRegions from -device for > SysBusDevices, that's a repeating topic really, and we already had one > KVM conference call on that topic with no solution emerging. Otherwise > you could use -M none. I'm not writing lengthy replies here for fun! > > Please replace "sunxi" with a concrete board name on machine level > (e.g., "gooseberry", "cubieboard") and with a concrete SoC name on SoC > level, whether "sun4i", "sun4i-a10", "allwinner-a13" or anything unique, > so that your series can later be extended with additional SoC family > members and/or boards with more than just the SoC on it. > > =20 OK, let me change and re-post. Thanks! >>>>>> A practical aspect of modeling SoCs correctly is that they can more >>>>>> easily be reused across boards or modules, and you don't need to mess >>>>>> with machine-level cpu=5Fmodel if you have a fixed SoC-CPU mapping. >>>>>> >>>>>> >>>>>> =20 >>>> modeling SoC is good, but >>>> sorry, I can't assure that fixed mapping. >>>> >>>> =20 >>> See above. A10 / sun4i =3D> Cortex-A8, that's fixed, and then you can >>> properly embed the ARMCPU in an A10State/Sun4iState without pointer and >>> using object=5Finitialize(). >>> >>> It is your approach of a single "sunxi" machine and SunxiState that's >>> interfering with a fixed mapping AFAICT. Otherwise you'll need to >>> explain more verbose why the mapping is not assured, please. >>> >>> =20 >> I mean, e.g. A10 and A13 are different only on HDMI-transmitter and >> SATA-controller, >> but we have to have Sun4iState, and Sun5iState, I think. >> =20 > Without knowing the hardware details, that sounds okay to me. > > Alternatively name it after the one that's used on the board (A10) and > when someone actually needs the A13 then they can just derive a new type > with no functional changes. If they have, e.g., different MIDR values > then different types would be good for lack of property to set it. But > type name and struct name obviously don't need to match; you could even > use multi-level inheritance to model such a tree with an abstract > "sun4i" device and non-abstract A10 and A13 devices. > > =20 >> what I design is: >> we have a sunxi series as a machine, then >> for sunx4i, we specify -M sunxi -cpu cortex-a8 -device x1 ... >> for sunx5i, we specify -M sunxi -cpu cortex-a8 -device x2 ... >> for sunx7i, we specify -M sunxi -cpu cortex-a7 -devcie x3 ... >> for cubieboard, we specify -M sunxi -cpu -cortex-a8 -device x1 -device >> p1 ... >> =20 > And that is exactly what I am objecting to. For the Midway board we > asked the same change (there "Highbank" is a codename but it is unique > in referring to ECX-1000 model with Cortex-A9, with "Midway" being > ECX-2000 with Cortex-A15 [*] and thus -cpu cortex-a15 not working well, > cf. list archives). > Your prescribed use of -cpu argument interferes with my QOM/CPU > refactorings, with board vs. SoC layering and makes it more difficult > for the user. Your modeling seems centered on testing flavors of the > sunxi kernel that you possibly work on, whereas I am asking you to model > a board and then test that the intended kernel flavor runs on it. > > The cpu=5Fmodel string determines the type of the object to be > instantiated, plus possibly optional properties if we manage to go with > some form of generalization as proposed by Alexey. You cannot easily > pass all that through from machine to device level. Therefore the > recommendation is to have a SoC device where the CPU does not change > except for setting properties to enable/disable features or set reset > values etc. and to ignore -cpu on the command line. If we need to > instantiate the CPU during realization due to a typename property, then > the user will have no chance to inspect or tweak the CPU cores via QMP. > > If someone wants to volunteer to summarize or link this on the > QOMConventions Wiki page that would be appreciated BTW. :) > > [*] http://www.calxeda.com/products/ > > =20 >>> QOM uses a strict composition model. If you choose the physical board >>> you have, say a Gooseberry board, then modeling should be so that we use >>> qemu-system-arm -M gooseberry (without -cpu cortex-a8) >>> and /machine has-a child "a10" >>> which in turn has-a child "cp= u". >>> -M cubieboard and -M marsboard can then all reuse the allwinner-a10 SoC >>> device, and in the future you can then tweak CPU properties via QMP >>> after TypeInfo::instance=5Finit and before DeviceClass::realize. >>> -M cubieboard2 /machine by contrast has-a child "a20" >>> which has-a child "cpu[0= ]", >>> has-a child "cpu[1= ]". >>> >>> Like I said below, Peter Maydell should be able to guide you in more >>> detail for the exact naming and composition. >>> =20 > Regards, > Andreas > > =20 =