Anthony Liguori wrote: > Gregory Haskins wrote: > >>> While KVM will inevitably start requiring newer kernel versions, do we >>> really need to do it right now? Perhaps we could add dummy eventfd_* >>> functions to the module compat header? Then at least older kernels will >>> continue to work with in- kernel APIC disabled. >>> >>> >>> >> The plan as Avi and I agreed to (IIUC) is to support eventfd via the >> extern-compat header. The same could be said for HRT. I don't thing either >> one will be particularly pleasant to support in this fashion, but this is >> how he wants to do it. (Recall that I had abstracted the HRT in earlier >> versions which he requested to be removed, so I didnt bother with the >> eventfd interface). I agree that it will keep the kvm core code cleaner >> instead of having all these custom abstractions, so I see his point there. >> I'm just not looking forward to the compat work ;) >> >> That being said: Perhaps you just came up with a good compromise. The code >> is already structured to support both the old way and the new way. We could >> have the in-kernel modes disabled at compile time on older kernels. Thats >> probably a much better solution then trying to get HRT and eventfd emulated >> on, say, 2.6.9 ;) >> >> The implication here is that I don't plan on supporting new features via the >> old-way. For instance, SMP features would only work with in-kernel >> emulation. If we go down this route, it automatically means that older >> kernels will not have any other related advanced features, not just the >> performance/features currently offered. Perhaps this is acceptable also? >> I'm not sure. >> >> > > I don't know. I'm less concerned about long term implications than I am > with short term ones. My primary concern was having new versions of KVM > stop working on older kernels. If SMP requires in-kernel APIC, then > provided that UP kernels still work, if someone is sufficiently > motivated to get SMP working on older kernels, they can implement the > eventfd emulation. > >
I'm not worried about eventfd -- we can just ship a conditionally-compiled copy of the code with the external module (we also need a non-syscall interface, as modules can't provide syscalls, but that's easily workaroundable). hrtimers is more difficult, but there's really no choice -- we can't #ifdef the core code for that. I really would like to see smp working without kernel apic, as pure qemu supports it. It would of course require newer modules. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
