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.
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.
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.
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.
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?
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.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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
