Great job Hollis! > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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/[EMAIL PROTECTED]: clock-frequency <- a8c000 (11MHz) > /plb/opb/[EMAIL PROTECTED]: clock-frequency <- a8c000 (11MHz) > /plb/opb/[EMAIL PROTECTED]: clock-frequency <- a8c000 (11MHz) > /plb/opb/[EMAIL PROTECTED]: 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 ([EMAIL PROTECTED]) (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 <[EMAIL PROTECTED]> > > -- > 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
