From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: QEMU PIC indirection patch for in-kernel APIC work Date: Wed, 04 Apr 2007 18:06:47 +0300 Message-ID: <4613BF07.50606@qumranet.com> References: <4610A6A9.BA47.005A.0@novell.com> <46134B74.1080004@qumranet.com> <4613B438.60107@codemonkey.ws> <4613B89F.8090806@qumranet.com> <4613BC6B.1070708@codemonkey.ws> 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: <4613BC6B.1070708-rdkfGonbjUSkNkDKm+mE6A@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: > Avi Kivity wrote: >> Anthony Liguori wrote: >>> >>> Then again, are we really positive that we have to move the APIC >>> into the kernel? A lot of things will get much more complicated. >> >> The following arguments are in favor: >> - allow in-kernel paravirt drivers to interrupt the guest without >> going through qemu (which involves a signal and some complexity) >> - same for guest SMP IPI >> - reduced overhead for a much-loved hardware component (especially on >> Windows, where one regularly sees 100K apic updates a second) > > This is for the TPR right? VT has special logic to handle TPR > virtualization doesn't it? I thought SVM did too... > Yes, the TPR. Both VT and SVM virtualize CR8 in 64-bit mode. SVM also supports CR8 in 32-bit mode through a nwe instruction encoding, but nobody uses that to my knowledge. Maybe some brave soul can hack kvm to patch the new instruction in place of the mmio instruction Windows uses to bang on the tpr. >> The strength of these arguments increase as vmexit overhead decreases >> with improving hardware. > > Do you mean, the strength of these arguments decrease? :-) Nope, increase. Currently vmexit time dominates the privilege switch time to user mode. If vmexit time is reduced to be on par with syscall time, you get 50% saving (assuming tpr emulation is near-free, which it can be easily made to be). > >> >> Of course, pushing such a piece of misery into the kernel where it >> can cause much pain should not be done lightly. > > Right, so some arguments against: > - The cost to go to userspace is small compared to the cost of the > exit itself True now. False tomorrow (for some value of tomorrow). > - Maintaining hardware emulation in two places is going to suck True now. Even truer tomorrow. > - The need to have in-kernel backends for paravirt drivers should be > carefully considered. > > An in-kernel backend is certainly not necessary for disks. Agree. > If we can't drive network traffic fast enough from userspace, perhaps > we should consider improving the userspace interfaces. I'm open to suggestions. With an in-kernel backend, we can have copyless transmit and single-copy receive. With the current APIs, we can have single-copy transmit and 3-copy receive. I doubt we could improve it beyond (1, 2) without major hacking on non-kvm kernel interfaces. > > Originating disk IO from userspace is useful for support interesting > storage formats. Network IO from userspace is also interesting to > support things like slirp. Right. Nobody's suggesting removing it, however. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV