Hollis Blanchard 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? >
Consider a non-modular build; common code needs to call either svm_vcpu_load() or vmx_vcpu_load() depending on the current hardware. I imagine it could be done using linker tricks (duplicating the common code to be linked twice, once per subarch, and leaving a stub to detect which duplicate needs to be used), but I never found either the time or necessity to do them. > 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. > Do you plan to support multiple processor types in a single binary as well? Or require modules and compile them multiple times? (that was how AMD support was initially added; it was changed before merging). -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- 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
