Avi Kivity wrote: > Zhang, Xiantao wrote: >> Avi Kivity wrote: >> >>> Zhang, Xiantao wrote: >>> >>>> Hi, Avi >>>> This patchset intends to enable kvm/ia-64 to build kvm >>>> components in userspace. You know, current userspace code only >>>> supports x86 to build kvm components, but kvm/ia64 have to build >>>> kvm modules and qemu separately. In this way, it is not >>>> conveninent for user-ends, and kvm's release package can't >>>> include kvm/ia64 bits. To make kvm userspace more friendly and >>>> common, I re-organize the kernel directory of kvm-userspace.git, >>>> and create two sub-directory (x86 and ia64)to hold arch-specific >>>> source files. With its support, ia64's end-users can build >>>> kvm/ia64 components in the same way with ia32 side, and future >>>> kvm's release packages are also capable to include ia64 bits. >>>> Appreicate any review comments! >>>> >>>> >>>> >>> While I have no objection in principle, I don't understand the >>> motivation. kvm ia64 cannot be retrofitted to older kernels (since >>> some symbols are not exported). Why is it not sufficient to use the >>> kernel module from the kernel tree? >>> >> >> The motivation is that developers and testers have to upgrade their >> kernels if kernel's minor version changed, otherwise the module >> formats would be incompatible. > > I do this all the time; this isn't a problem for developers. Actually, so do I. But for testers or new comers, it maybe a big problem. >> Especially it is not convenient for some auto >> testing systems, because the upgrading kernel process would be more >> complex. > > I agree that for automatic testing it's more of a burden; but it needs > to be done, especially as some kvm features are only enabled on newer > kernels. > > The external module is convenient, but it's not a substitute for the > real thing. So, I have a question here, When will you drop external module support? You know, it blocks our auto-testing system now, we have to re-evaulate the effort without external module support. If it won't be dropped in a few weeks, we are eager to get its support for kvm-ia64. >> In addition, we can't alwasys require the end-users to use >> the lastest kvm.git bits as host kernels, especially for servers >> which may disallow to do a restart after enabling kvm on it. >> > > If the server is used primarily for virtualization, you will need to > stop all guests anyway. Agree. But for new users, it maybe a potential restart required for upgrading kernel. > kvm.git is certainly not suitable for end-users; they should use a > supported Linux distribution. The distro can choose whether to > include the upstream kvm, or it can backport kvm.git into its kernel > if it wants newer features. Backport maybe need more effort once without external module support. >>> Eventually, the x86 external module support will be dropped as well. >>> Most noncommercial distributions already have good kvm support; the >>> only questions is what to do with RHEL/SLES/CentOs users -- wait >>> until the next major release, or wait until ovirt starts shipping? >>> >> >> >> >>> Note that mmu notifiers further reduce the attractiveness of the >>> external module, unless someone manages to backport it to older >>> kernels. >>> >> Yes, that maybe a big problem for external module. But for ia64, we >> don't want to support kernels whose version is less than 2.6.26. >> However, when kernel's version grows to 2.6.27 or bigger, we have to >> provide the backward compatiblity for 2.6.26. Agree? >> > > 2.6.26 has not been released! Is this a real problem or a theoretical > problem? >From the long run, the problem should exist. IMO, we had better provide external module support for some recent kernel versions, instead of canceling it. >> Moreover, the users are using Linux-2.6.26, and don't want to >> upgrade their kernels, but they want to use latest kvm bits to run >> guests. How to meet such the requirement in a easy way? So, I think >> external module should be a better way to adopt. >> > > Well the same problem exists for network drivers. The kernel.org > solution is to use the newer kernel, the distro solution is to > backport the changes to the older kernel, if there is user demand. > > As I mentioned, I'm not opposed in principle, but I want to be sure > we're solving a real problem, since external module maintenance is not > trivial. -- To unsubscribe from this list: send the line "unsubscribe kvm-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
