Re: PowerPC 440 progress

Tim Anderson
2007-09-19T00:32:45Z

Great job Hollis!

> -----Original Message-----
> From: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> [mailto:kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of
> Hollis Blanchard
> Sent: Tuesday, September 18, 2007 3:42 PM
> To: kvm-ppc-devel
> Cc: kvm-devel
> Subject: [kvm-devel] PowerPC 440 progress
>
> With the attached patch, we can now execute a 440 Linux guest on a 440
> host through many initcalls:
>
> CPU clock-frequency <- 0x27bc86ae (667MHz)
> CPU timebase-frequency <- 0x27bc86ae (667MHz)
> /plb: clock-frequency <- 9ef21ab (167MHz)
> /plb/opb: clock-frequency <- 4f790d5 (83MHz)
> /plb/opb/ebc: clock-frequency <- 34fb5e3 (56MHz)
> /plb/opb/serial@ef600300: clock-frequency <- a8c000 (11MHz)
> /plb/opb/serial@ef600400: clock-frequency <- a8c000 (11MHz)
> /plb/opb/serial@ef600500: clock-frequency <- a8c000 (11MHz)
> /plb/opb/serial@ef600600: clock-frequency <- a8c000 (11MHz)
> Memory <- <0x0 0x0 0x9000000> (144MB)
> ENET0: local-mac-address <- 00:00:00:00:00:00
> ENET1: local-mac-address <- 00:00:00:00:00:00
>
> zImage starting: loaded at 0x00400000 (sp: 0x00fffe98)
> Allocating 0x263c5c bytes for kernel ...
> gunzipping (0x00000000 <-
> 0x0040b000:0x00661acc)...done 0x243a9c bytes
>
> Linux/PowerPC load:
> Finalizing device tree... flat tree at 0x66e3a0
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> Using Bamboo machine description
> Linux version 2.6.23-rc1 (hollisb@basalt) (gcc
> version 3.4.2) #88 Tue Sep 18 17:18:36 CDT 2007
> console [udbg0] enabled
> setup_arch: bootmem
> arch: exit
> Zone PFN ranges:
> DMA 0 -> 36864
> Normal 36864 -> 36864
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0 -> 36864
> Built 1 zonelists in Zone order. Total pages: 36576
> Kernel command line: console=ttyS0 debug
> UIC0 (32 IRQ sources) at DCR 0xc0
> UIC1 (32 IRQ sources) at DCR 0xd0
> PID hash table entries: 1024 (order: 10, 4096 bytes)
> time_init: decrementer frequency = 666.666670 MHz
> time_init: processor frequency = 666.666670 MHz
> Dentry cache hash table entries: 32768 (order: 5,
> 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 143500k/147456k available (2192k kernel code,
> 3816k reserved, 100k data, 127k bss, 124k init)
> Calibrating delay loop... 1167.36 BogoMIPS (lpj=2334720)
> Mount-cache hash table entries: 512
> NET: Registered protocol family 16
>
> PCI: Probing PCI hardware
> NET: Registered protocol family 2
> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> TCP established hash table entries: 8192 (order: 4,
> 65536 bytes)
> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP reno registered
> io scheduler noop registered
> io scheduler anticipatory registered (default)
> io scheduler deadline registered
> io scheduler cfq registered
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports,
> IRQ sharing enabled
>
> The guest currently seems to be stuck in the serial driver
> reading IER.
> Qemu doesn't seem to be getting the accesses though, so more debugging
> is required.
>
> Also, signal delivery and scheduling other host tasks are now working,
> which makes for a nicer development environment. If you run "gdb qemu"
> on the host, you can at least do a post-mortem of guest memory.
>
> Interesting note (at least, I thought it was interesting): since the
> guest can read the timebase without trapping, we must always
> report the
> real timebase frequency to the guest.
>
> The easiest way to do this right now was to implement DCR-read
> passthrough, since that's where the Linux bootwrapper gets the
> frequencies for the device tree. Long-term, we may want to have qemu
> supply a device tree itself (but it still must report the real
> frequency).
>
> Another interesting note: since the guest can read SPRG4-7 without
> trapping, we must context-switch those registers.
>
> Signed-off-by: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> --
> Hollis Blanchard
> IBM Linux Technology Center
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.