From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 5/9] KVM: Adds ability to signal userspace using a file-descriptor Date: Tue, 15 May 2007 13:44:11 -0500 Message-ID: <4649FF7B.10107@us.ibm.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Gregory Haskins Return-path: In-Reply-To: <4649AD87.BA47.005A.0-Et1tbQHTxzrQT0dZR+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 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. Regards, Anthony Liguori > Regards, > -Greg > > > > ------------------------------------------------------------------------- > 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > ------------------------------------------------------------------------- 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/