| Message ID | 52AA31A8.4010806@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 2013-12-12 22:59, Paolo Bonzini wrote: > Il 12/12/2013 22:27, Gabriel L. Somlo ha scritto: >> I tried copying and/or cut'n'pasting from additional source files in >> the current kvm git tree, but haven't totally figured out how the magic >> of "make sync" works yet :) Do you have any notes or any other >> documentation one could use to be able to usefully hack on kvm-kmod >> when it starts lagging behind the latest kvm master branch ? > > You need to "hack" the ./sync script to generate the appropriate > #ifdefs. > > It looks like the code to support newer releases is currently in the > next branch of kvm-kmod.git. Yes, kvm-kmod is starting to bitrot. I just noticed I messed up the last stable release back in August, and no one seems to have noticed it. There were no complains about the missing releases for 3.11 and 3.12, so it the relevance must have dropped significantly. kvm-kmod is still useful for hacking, so I'm considering to stop providing releases (except for a final 3.10.21), just updates in git to allow wrapping of latest kvm head on recent kernels. There are breakages with kernels < 3.0 now, about which I personally do not care anymore, so lifting the entrance level to 3.0 seems reasonable. > > For completeness, here is the patch I am using right now. Is there anything in your patch that is still required with current kvm-kmod next? Then I would be happy about a patch! Jan
Il 13/12/2013 16:04, Jan Kiszka ha scritto: > Yes, kvm-kmod is starting to bitrot. I just noticed I messed up the last > stable release back in August, and no one seems to have noticed it. > There were no complains about the missing releases for 3.11 and 3.12, so > it the relevance must have dropped significantly. I think the relevance of releases is ~zero. kvm-kmod still remains extremely useful IMHO as a hacking tool. > kvm-kmod is still useful for hacking, so I'm considering to stop > providing releases (except for a final 3.10.21), just updates in git to > allow wrapping of latest kvm head on recent kernels. Yes, git can be good enough for distribution. > There are breakages > with kernels < 3.0 now, about which I personally do not care anymore, so > lifting the entrance level to 3.0 seems reasonable. Agreed on this as well. Personally I would be fine even with only 3-4 releases backwards compatibility (e.g. 3.8) right now. >> > For completeness, here is the patch I am using right now. > Is there anything in your patch that is still required with current > kvm-kmod next? Then I would be happy about a patch! Your next branch works for me. The only difference between my patch and your origin/next is that I'm copying %(linux)s/arch/%(arch)s/include/uapi/asm/msr-index.h' and you have + +#ifndef MSR_IA32_VMX_MISC_PREEMPTION_TIMER_SCALE +#define MSR_IA32_VMX_MISC_PREEMPTION_TIMER_SCALE 0x1F +#endif Everything else is roughly the same. Thanks for maintaining kvm-kmod! Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2013-12-13 16:12, Paolo Bonzini wrote: > Il 13/12/2013 16:04, Jan Kiszka ha scritto: >> Yes, kvm-kmod is starting to bitrot. I just noticed I messed up the last >> stable release back in August, and no one seems to have noticed it. >> There were no complains about the missing releases for 3.11 and 3.12, so >> it the relevance must have dropped significantly. > > I think the relevance of releases is ~zero. kvm-kmod still remains > extremely useful IMHO as a hacking tool. Exactly. > >> kvm-kmod is still useful for hacking, so I'm considering to stop >> providing releases (except for a final 3.10.21), just updates in git to >> allow wrapping of latest kvm head on recent kernels. > > Yes, git can be good enough for distribution. > >> There are breakages >> with kernels < 3.0 now, about which I personally do not care anymore, so >> lifting the entrance level to 3.0 seems reasonable. > > Agreed on this as well. Personally I would be fine even with only 3-4 > releases backwards compatibility (e.g. 3.8) right now. > >>>> For completeness, here is the patch I am using right now. >> Is there anything in your patch that is still required with current >> kvm-kmod next? Then I would be happy about a patch! > > Your next branch works for me. The only difference between my patch and > your origin/next is that I'm copying > > %(linux)s/arch/%(arch)s/include/uapi/asm/msr-index.h' > > and you have > > + > +#ifndef MSR_IA32_VMX_MISC_PREEMPTION_TIMER_SCALE > +#define MSR_IA32_VMX_MISC_PREEMPTION_TIMER_SCALE 0x1F > +#endif Indeed, will change this. Thanks! Jan > > Everything else is roughly the same. Thanks for maintaining kvm-kmod! > > Paolo >
diff --git a/sync b/sync index 273ec5b..0e7ab14 100755 --- a/sync +++ b/sync @@ -196,7 +196,7 @@ def hack_content(fname, data): w('\tkvm_xstate_size_init();\n') if match_block_end(r'case CPU_STARTING:', r'hardware_enable'): w('#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28)') - w('\t\thardware_enable(NULL);') + w('\t\thardware_enable();') w('#else') w('\t\tsmp_call_function_single(cpu, hardware_enable, NULL, 1);') line = '#endif' @@ -321,6 +321,13 @@ def hack_content(fname, data): w('#else') w('\tif (!kvm_cpu_has_amd_erratum(kvm_amd_erratum_383))') line = '#endif' + if line == '\t.count_objects = mmu_shrink_count,': + w('#if LINUX_VERSION_CODE >= KERNEL_VERSION(3,12,0)') + if line == '\t.scan_objects = mmu_shrink_scan,': + w(line) + w('#else') + w('\t.shrink = mmu_shrink,') + line = '#endif' w(line) if line == '\tkvm_arch_vcpu_put(vcpu);': w('\tkvm_fire_urn();') @@ -358,6 +365,14 @@ def hack_content(fname, data): w('#endif') if line == '#define _ASM_X86_KVM_HOST_H': w('#include <linux/clocksource.h>') + if match_block_end(r'^mmu_shrink_count', r'^}'): + w('#if LINUX_VERSION_CODE <= KERNEL_VERSION(3,12,0)') + w('static int mmu_shrink(struct shrinker *shrink, struct shrink_control *sc)') + w('{') + w('\tif (sc->nr_to_scan != 0) mmu_shrink_scan(shrink, sc);'); + w('\treturn mmu_shrink_count(shrink, sc);'); + w('}') + w('#endif') if eventfd_file: result.append('#else\n' 'void kvm_eventfd_init(struct kvm *kvm) { }\n' @@ -443,6 +458,7 @@ def header_sync(arch): for dir in ['%(linux)s/arch/%(arch)s/include/uapi/asm/kvm*.h', '%(linux)s/arch/%(arch)s/include/uapi/asm/vmx.h', '%(linux)s/arch/%(arch)s/include/uapi/asm/svm.h', + '%(linux)s/arch/%(arch)s/include/uapi/asm/msr-index.h', '%(linux)s/arch/%(arch)s/include/uapi/asm/hyperv.h'] for x in glob(dir % { 'arch': arch, 'linux': linux }) ]) diff --git a/x86/external-module-compat.h b/x86/external-module-compat.h index e5039a6..7acd97e 100644 --- a/x86/external-module-compat.h +++ b/x86/external-module-compat.h @@ -23,6 +23,13 @@ typedef u64 phys_addr_t; #define cpu_has_hypervisor boot_cpu_has(X86_FEATURE_HYPERVISOR) #endif +#if LINUX_VERSION_CODE < KERNEL_VERSION(3,12,0) +static inline int hypervisor_cpuid_base(const char *sig, uint32_t leaves) +{ + return 0; +} +#endif + #include "../external-module-compat-comm.h" #include <asm/msr.h>