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 _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
