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. Especially it is not convenient for some auto testing systems, because the upgrading kernel process would be more complex. 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. > 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? 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. >> PS: To make it reviewable, I splited it into small patches. The >> first five patches intends to move x86 specific files to x86 >> directory, the sixth one for enabling Kbuild in new laylout. The >> last one makes kvm/ia64 build components in userspace. >> > > Please generate patches with the '-M' option (or set the > 'diff.renames' config option) so file movement patches show up as > such. Good idea! Thanks Xiantao -- 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
