Re: PowerPC 440 progress

["Tim Anderson" <tanderson-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>]

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.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/