From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Date: Fri, 14 Dec 2007 00:01:41 +0000 Subject: Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log Message-Id: <1197590501.28334.10.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 Thu, 2007-12-13 at 18:14 +0800, Zhang Wei wrote: > > From: Hollis Blanchard [mailto:hollisb@us.ibm.com] > > > > 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. > > > > Do you mind send out the asm-offsets.h? Maybe I can take it base on the > hack code. Oh, the file is the same. The problem is how to have Kbuild automatically generate it. > > > > 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. > > > > Oh, it is supposed to be a good idea. Howeve, can we know which target > the guest os is for, Book III-S or Book III-E(440, E500)? > If we can tell it, we could add supported guest module, such as 440, > e500, e600, into one fix table to fit the individual guest os. I think that's a VM creation parameter. When userspace creates the VM (including memory and vcpu allocation), it can specify to the kernel which core to emulate. -- 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