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 10:51:47 -0500 Message-ID: <4613C993.9020405@codemonkey.ws> References: <4610A6A9.BA47.005A.0@novell.com> <46134B74.1080004@qumranet.com> <4613B438.60107@codemonkey.ws> <4613B89F.8090806@qumranet.com> <4613BC6B.1070708@codemonkey.ws> <4613BF07.50606@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: <4613BF07.50606-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: >> 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. It seems like that shouldn't be too hard assuming that the MMIO instructions are <= the new CR8 instruction. It would require knowing where the TPR is mapped into memory of course. If we do this, then we can probably just handle the TPR as a special case anyway and not bother returning to userspace when the TPR is updated through MMIO. That saves the round trip without adding emulation complexity. >> 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. I don't know enough about networking to speak intelligently here so I'll just defer to the experts :-) Regards, Anthony Liguori >> >> 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. > ------------------------------------------------------------------------- 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