From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 5/9] KVM: Adds ability to signal userspace using a file-descriptor Date: Wed, 16 May 2007 14:56:33 +0300 Message-ID: <464AF171.1050202@qumranet.com> References: <20070515145404.15609.61552.stgit@novell1.haskins.net> <20070515145759.15609.34720.stgit@novell1.haskins.net> <4649E22F.3090308@us.ibm.com> <4649AD87.BA47.005A.0@novell.com> <4649FF7B.10107@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Anthony Liguori Return-path: In-Reply-To: <4649FF7B.10107-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org 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/