Re: [Qemu-devel] [PATCH v4 3/4] hw/arm: add sunxi machine type

[Andreas Färber]

Am 29.11.2013 09:06, schrieb Li Guang:
> Andreas Färber wrote:
>> Am 29.11.2013 01:46, schrieb Li Guang:
>>   
>>> Andreas Färber wrote:
>>>     
>>>> Am 27.11.2013 10:22, schrieb Andreas Färber:
>>>>
>>>>> [...] 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 = sun4i, A2x = sun5i, A3x = sun6i
>>>>> but
>>>>>
>>>>>          
>>>> My interpolation was incorrect: A10 = sun4i, A13 = sun5i, A3x = sun6i,
>>>> A20 = sun7i
>>>>       
>>>>> 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 whether
>>>>> the modeling is actually correct or which changes need to be
>>>>> performed.
>>>>>
>>>>>
>>>>>          
>>> well, sunxi maybe be representation of Axx series,
>>> but, what's wrong?
>>>      
>> 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é 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.
>>
>>   
>>> we can't track Axx hardware changes? why?
>>>      
>> 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.
>>    
> 
> right, A10/20... seem have similar devices except CPU
> 
>> 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_priv" composite device.
>> http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores#Designed_by_ARM
>>
>>
>>   
>>> and also, this patch-set is also community effort just like
>>> sunxi in linux kernel.
>>>      
>> 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. :)
>>
>>    
> 
> of course, I am aiming to emulate the real hardware,
> so name is not the problem, right?

It is. The x in sunxi appears to be a wildcard.

Quoting http://linux-sunxi.org/Main_Page:
"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.

>>>>> 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_model if you have a fixed SoC-CPU mapping.
>>>>>
>>>>>          
>>> modeling SoC is good, but
>>> sorry, I can't assure that fixed mapping.
>>>      
>> See above. A10 / sun4i =>  Cortex-A8, that's fixed, and then you can
>> properly embed the ARMCPU in an A10State/Sun4iState without pointer and
>> using object_initialize().
>>
>> 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.
>>    
> 
> 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.

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.

> 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 ...

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_model 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/

>> 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<allwinner-a10>  "a10"
>>                     which in turn has-a child<cortex-a8-arm-cpu>  "cpu".
>> -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_init and before DeviceClass::realize.
>> -M cubieboard2 /machine by contrast has-a child<allwinner-a20>  "a20"
>>                          which has-a child<cortex-a7-arm-cpu>  "cpu[0]",
>>                                has-a child<cortex-a7-arm-cpu>  "cpu[1]".
>>
>> Like I said below, Peter Maydell should be able to guide you in more
>> detail for the exact naming and composition.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg