From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Date: Wed, 12 Dec 2007 19:19:21 +0000 Subject: Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log Message-Id: <1197487161.26038.30.camel@basalt> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ppc@vger.kernel.org On Wed, 2007-12-12 at 19:57 +0800, Zhang Wei wrote: > > > > Congratulations! :) Will you send patches? What are your > > thoughts on the > > commonality between 440 and e500 code? > > Thanks! The MMU and some core registers are different, but almost of the > other can be reused. So I change 440 TLB functions to core independence > API and add an exceptions_e500.S file. Interesting, good to know. > > We haven't touched the "hack" code recently, since we've been > > refactoring the upstream tree. That's pretty much done > > though, and right > > now I'm just starting to integrate the old 440 support with the new > > upstream code. That's not in a good state right now, but I could clean > > it up and send it out if you're interested. > > Yes! I think hack codes are only for verifying the idea. Our target is > for upstream code. I hope I could join you! Well, unfortunately at the moment I'm just fighting with asm-offsets.h . :( Since I'm basically already on vacation, I'm not sure I'll be able to get anything ready until January. > > Also, I'm messing around with Makefiles now, and have been thinking > > about how to connect the modules... For example, should there be a > > kvm-powerpc-guest-440.ko that could link with > > kvm-powerpc-host-e500.ko? > > For now, a single kvm-powerpc-e500.ko (e500 guests on e500 host) is > > probably easiest, but we should think about the long-term goal too. > > > > I will make some studies about this. What's kvm-guest-xxx.ko and > kvm-host-xxx.ko? > Why not one kvm-powerpc.ko? Books 1 and 2 are (more or less) identical across PowerPC. Book 3 is where the big differences are, but we are emulating all Book 3 stuff in software. That means we can emulate whatever Book 3 we want; we don't need to run only e500 guests on e500 hosts. So, we could in theory have a module that e.g. emulates the e500 Book 3, which we'd call something like kvm-powerpc-e500-guest.ko. If we emulate tlbwe with HTAB modifications, we could run e500 guests on an e600. We would call the module with the HTAB logic something like kvm-powerpc-e600-host.ko. The important point for the MMU is that all PPC have the concept of a virtual address, which is an effective address + some context identifier. On classic or server PPC, that context comes from segmentation (SRs, SLB, or STAB), whereas on Book E the context is AS + PID. It's just a (maybe crazy) idea, but if we're clever we might actually get it to work. Of course, since you guys have a few different embedded cores, that might be of more interest to your company than mine... > > By the way, we booted with an initrd so we wouldn't need the network, > > and hacked the device tree not to use interrupts for the UART. If you > > take shortcuts like that you can really minimize your > > dependency on qemu for now. > > How about the qemu position in our roadmap? If it still be the key role, > I'll have to add some e500 hw drivers into it. Yeah, that's a good question. I believe that emulating complex IP blocks (e.g. IBM EMAC, Freescale TSEC) would take significant effort. Instead I'm going to be trying alternatives, such as an x86-like "virtual board" or virtual IO drivers. In the first case, you pretend you have a bare core (without any SoC peripherals) on a board with x86 devices. Qemu supports a set of x86 devices, so instead of writing all the TSEC emulation, you would just tell the guest it has a Realtek NIC. Guests may already have device drivers for "standard" devices like these. Qemu will also gain virtual IO support in the future, which is basically idealized IO devices to increase performance by using a virtualization-friendly design (e.g. minimize MMIO accesses). The down side is that guests would need new device drivers for this. That said, we'd probably want to stick with emulated versions of simple/critical PPC devices like the interrupt controller, so you might have a little work to do there. Personally I don't think writing all the SoC device emulation from scratch is a realistic goal, at least not for me. You're welcome to prioritize whatever you want of course. :) -- Hollis Blanchard IBM Linux Technology Center ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-ppc-devel mailing list kvm-ppc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel