From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: [PATCH 0 of 3] create kvm_x86 Date: Fri, 30 Nov 2007 16:08:10 -0600 Message-ID: <1196460490.7103.67.camel@basalt> References: <4743F5AE.8090707@de.ibm.com> <4743F7DF.4000107@qumranet.com> <1196284556.9247.22.camel@basalt> <474FBB17.6080800@qumranet.com> <42DFA526FC41B1429CE7279EF83C6BDCA397C1@pdsmsx415.ccr.corp.intel.com> <474FD234.5060203@qumranet.com> <1196448210.7103.47.camel@basalt> <4750732B.7070502@qumranet.com> <1196456956.7103.60.camel@basalt> <47508408.8050202@codemonkey.ws> Reply-To: Hollis Blanchard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org, kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, kvm-ppc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, "Zhang, Xiantao" , Avi Kivity To: Anthony Liguori Return-path: In-Reply-To: <47508408.8050202-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Fri, 2007-11-30 at 15:43 -0600, Anthony Liguori wrote: > Hollis Blanchard wrote: > > On Fri, 2007-11-30 at 22:31 +0200, Avi Kivity wrote: > > > >> These cannot use the same method, since we need to support both vmx and > >> svm in the same binary. The arch specific members aren't the same size, > >> nor do the symbols they use have the same visibility. > >> > > > > I have never understood this. Why on earth do you need to support VMX > > and SVM in the same binary? For example, when would you overwrite > > kvm_x86_ops after initialization? If you wouldn't, then why are you > > using function pointers instead of the linker? > > > > It's necessary for the distros to be able to ship both AMD and Intel > support in a single binary. We aren't talking, in general, about a > single static binary but instead loadable modules. There maybe some > cases where it's useful to support both in a static kernel binary. I think the monolithic case is the one I overlooked. As long as everything is a module, there should be no problem loading the appropriate module for the host processor type. However, once you want to support both processor types in a monolithic kernel, that's where you need the function pointer flexibility. > If you used the linker instead of function pointers, it would be > impossible to build a static kernel binary that supported both. Plus, > depmod would get very confused because two modules would be providing > the same symbols. It can be made to work, but it's kind of funky. > > > PowerPC will also need to support multiple processor types, and so I > > expect to have one kvm_arch structure for each. That also means struct > > kvm_arch must be the *last* member in struct kvm, which is not how it is > > shown above. > > > > Instead of having a kvm.ko and a kvm-ppc-440.ko, you probably should > have a kvm.ko and a kvm-ppc.ko and then build the kvm-ppc.ko based on > the board. You would never build multiple kvm-ppc-XXX.ko modules in the > same binary right? I hope to have multiple kvm-ppc-XXX.ko modules loaded simultaneously to support different guest types on the same host. I haven't yet figured out what that interface should look like, but obviously linking is preferable to function pointers where feasible. -- Hollis Blanchard IBM Linux Technology Center ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4