[v8,0/3] hw/arm: Add 'virt' platform

This patch series adds a 'virt' platform which uses the
kernel's mach-virt (fully device-tree driven) support
to create a simple minimalist platform intended for
use for KVM VM guests.

v6->v7 change is just flipping the order we put
the virtio nodes into the device tree, to match
vexpress and ppc precedent.

Since that's a pretty minor change I plan to put this
into a pullreq to go into 1.7 soonish (read: probably
this weekend). Yell now if you disagree.


Sample command line:

 qemu-system-arm -machine type=virt -display none \
  -kernel zImage \
  -append 'root=/dev/vda rw console=ttyAMA0 rootwait'
  -cpu cortex-a15 \
  -device virtio-blk-device,drive=foo \
  -drive if=none,file=arm-wheezy.img,id=foo \
  -m 2048 -serial stdio

Note that there is no earlyprintk via the PL011 because
there's no defined device tree binding for "hey, here
is your earlyprintk UART".


*** NOTE *** to get the PL011 to work you'll need to
tweak the kernel a bit:


Otherwise the kernel doesn't ever add the clock to its
list, and then it refuses to probe for the PL011.
(I'm told this isn't really the right fix, though, and
ideally the call should be done in some generic location
rather than in every machine's init function.)

The alternative would be for the kernel to be fixed to
follow its own device tree binding documentation and not
require clocks/clock-names properties on the pl011 node.


Changes from John Rigby's v3->my v4:
 * renamed user-facing machine to just "virt"
 * removed the A9 support (it can't work since the A9 has no
   generic timers)
 * added virtio-mmio transports instead of random set of 'soc' devices
 * instead of updating io_base as we step through adding devices,
   define a memory map with an array (similar to vexpress)
 * folded in some minor fixes from John's aarch64-support patch
 * rather than explicitly doing endian-swapping on FDT cells,
   use fdt APIs that let us just pass in host-endian values
   and let the fdt layer take care of the swapping
 * miscellaneous minor code cleanups and style fixes
Changes v4->v5:
 * removed outdated TODO remarks from commit messages
Changes v5->v6:
 * adjusted the memory map as per Anup's review comments
   (actually made the changes this time!)
Changes v6->v7:
 * added a PL011 UART, at Alex's suggestion (and the accompanying
   fake clock dtb node that this requires)
 * added an irqmap[] in parallel with the memmap[] so that our
   assignment of devices to irq lines is neatly in one place
 * the removal of arm_pic allows us to get rid of an irritating
   array sized to the number of CPUs
 * included the "terminate dtb reservemap" patch since it's a
   dependency to get the kernel to boot
Changes v7->v8:
 * iterate through virtio-mmio nodes the opposite way round so
   that they appear in the device tree lowest-address-first;
   this matches PPC behaviour and the vexpress code

John Rigby (1):
  hw/arm/boot: Allow boards to provide an fdt blob

Peter Maydell (2):
  device_tree.c: Terminate the empty reservemap in create_device_tree()
  hw/arm: Add 'virt' platform

 device_tree.c        |    4 +
 hw/arm/Makefile.objs |    2 +-
 hw/arm/boot.c        |   32 ++--
 hw/arm/virt.c        |  418 ++++++++++++++++++++++++++++++++++++++++++++++++++
 include/hw/arm/arm.h |    7 +
 5 files changed, 450 insertions(+), 13 deletions(-)
 create mode 100644 hw/arm/virt.c

On Thu, Oct 17, 2013 at 05:48:43PM +0100, Peter Maydell wrote:
> This patch series adds a 'virt' platform which uses the
> kernel's mach-virt (fully device-tree driven) support
> to create a simple minimalist platform intended for
> use for KVM VM guests.
> 
> v6->v7 change is just flipping the order we put
> the virtio nodes into the device tree, to match
> vexpress and ppc precedent.

that's v7->v8 changes right?

-Christoffer

On 17 October 2013 18:05, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> On Thu, Oct 17, 2013 at 05:48:43PM +0100, Peter Maydell wrote:
>> This patch series adds a 'virt' platform which uses the
>> kernel's mach-virt (fully device-tree driven) support
>> to create a simple minimalist platform intended for
>> use for KVM VM guests.
>>
>> v6->v7 change is just flipping the order we put
>> the virtio nodes into the device tree, to match
>> vexpress and ppc precedent.
>
> that's v7->v8 changes right?

doh, yes.

-- PMM

On 17 October 2013 17:48, Peter Maydell <peter.maydell@linaro.org> wrote:
> This patch series adds a 'virt' platform which uses the
> kernel's mach-virt (fully device-tree driven) support
> to create a simple minimalist platform intended for
> use for KVM VM guests.

> Changes v7->v8:
>  * iterate through virtio-mmio nodes the opposite way round so
>    that they appear in the device tree lowest-address-first;
>    this matches PPC behaviour and the vexpress code

...it turns out this isn't quite right. We need to create
the actual devices in forwards order (so that devices created
on the qemu command line populate the transports lowest address
first) and then create the dtb nodes in reverse order (so that
the transports appear in the final dtb lowest address first). Ugh.

Given this plus the fact that you still need a kernel patch to
get the thing to boot at all [would anybody on the kernel side
like to pick up that particular ball?], I'm leaning toward not
putting this in 1.7 now.

-- PMM

On 18.10.2013, at 13:12, Peter Maydell <peter.maydell@linaro.org> wrote:

> On 17 October 2013 17:48, Peter Maydell <peter.maydell@linaro.org> wrote:
>> This patch series adds a 'virt' platform which uses the
>> kernel's mach-virt (fully device-tree driven) support
>> to create a simple minimalist platform intended for
>> use for KVM VM guests.
> 
>> Changes v7->v8:
>> * iterate through virtio-mmio nodes the opposite way round so
>>   that they appear in the device tree lowest-address-first;
>>   this matches PPC behaviour and the vexpress code
> 
> ...it turns out this isn't quite right. We need to create
> the actual devices in forwards order (so that devices created
> on the qemu command line populate the transports lowest address
> first) and then create the dtb nodes in reverse order (so that
> the transports appear in the final dtb lowest address first). Ugh.
> 
> Given this plus the fact that you still need a kernel patch to
> get the thing to boot at all [would anybody on the kernel side
> like to pick up that particular ball?], I'm leaning toward not
> putting this in 1.7 now.

We could add a fdt_append_subnode_namelen() function that instead of putting it after the parent's properties puts the new node after all subnodes. While we're waiting for it to trickle into libfdt we could keep a copy in device_tree.c.

Then we just switch everything to "natural" non-reverse order append_subnode().


Alex