From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: QEMU PIC indirection patch for in-kernel APIC work Date: Wed, 04 Apr 2007 09:55:39 -0500 Message-ID: <4613BC6B.1070708@codemonkey.ws> References: <4610A6A9.BA47.005A.0@novell.com> <46134B74.1080004@qumranet.com> <4613B438.60107@codemonkey.ws> <4613B89F.8090806@qumranet.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: Avi Kivity Return-path: In-Reply-To: <4613B89F.8090806-atKUWr5tajBWk0Htik3J/w@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 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... > The strength of these arguments increase as vmexit overhead decreases > with improving hardware. Do you mean, the strength of these arguments decrease? :-) > > 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 - Maintaining hardware emulation in two places is going to suck - The need to have in-kernel backends for paravirt drivers should be carefully considered. An in-kernel backend is certainly not necessary for disks. If we can't drive network traffic fast enough from userspace, perhaps we should consider improving the userspace 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. Regards, Anthony Liguori ------------------------------------------------------------------------- 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