From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: User space for lapic2 Date: Tue, 10 Jul 2007 16:07:46 +0300 Message-ID: <469384A2.1070407@qumranet.com> References: <10EA09EFD8728347A513008B6B0DA77A01BD792E@pdsmsx411.ccr.corp.intel.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: "Dong, Eddie" Return-path: In-Reply-To: <10EA09EFD8728347A513008B6B0DA77A01BD792E-wq7ZOvIWXbNpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@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 Dong, Eddie wrote: > kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote: > >> Avi Kivity wrote: >> >>> Dong, Eddie wrote: >>> >>>> Avi: >>>> To make lapic code into mainline earlier, I am thinking what >>>> should the user space code look like. If we wait till lapic branch >>>> has all same functionality as mainline have today i.e. live >>>> migration, all guests etc, we may have very long way to go given >>>> that only Greg (temply off), me have contribution to the code >>>> besides you. So what I am thinking is to reduce the bar to "no >>>> regression", which means a user space command to choice kernel >>>> pic/apic. When choosing user pic/apic, we make sure everything works >>>> including livemigration and all known good guests; if choosing >>>> kernel pic/apic, we have better performance but some feature lagging >>>> such as live migration. Does this make sense? If yes, How about >>>> command option "-irqchip k" and "-irqchip u"? the default value is >>>> user. >>>> >>>> >>> That doesn't work; one day we'll make kernel apic the default, and >>> then that new userspace won't work with kernels that have in-kernel >>> pic but not lapic. >>> >>> >> After we get everything settled down, we can switch the default >> setting to "kernel". BTW, I am talking about generic lapic solution, >> not current one in lapic2 branch. Definitely we need to pull in >> kernel apic+ioapic first before the push back. But I think now we >> should make a high level decision on how we will handle this merge >> and how will user space look like. >> >> > Avi: > Can u show clear light here? We need to go forward quickly:-) > Eddie > If we release a kernel with pic but not lapic, and userspace that defaults to user-pic+lapic, then that kernel will not work with a newer userspace that defaults to in-kernel pic+lapic. We need to switch in one go. I don't mind checking in patches to the lapic2 branch, and continually rebasing it against master, but a release will only happen when everything works. -- 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/