From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4qMQ-0003Xa-0L for qemu-devel@nongnu.org; Thu, 22 Apr 2010 02:58:06 -0400 Received: from [140.186.70.92] (port=59989 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4qMB-0003Qz-9I for qemu-devel@nongnu.org; Thu, 22 Apr 2010 02:58:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4qM7-0003cV-AY for qemu-devel@nongnu.org; Thu, 22 Apr 2010 02:57:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50606) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4qM6-0003bu-W4 for qemu-devel@nongnu.org; Thu, 22 Apr 2010 02:57:47 -0400 Message-ID: <4BCFF367.9090608@redhat.com> Date: Thu, 22 Apr 2010 09:57:43 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: QEMU-KVM and video performance References: <4BCEBE5C.4020404@redhat.com> <20100421100840.GF13114@shareable.org> <4BCED82C.9020702@redhat.com> <4BCF64E9.4090909@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerhard Wiesinger Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 04/22/2010 08:37 AM, Gerhard Wiesinger wrote: > On Wed, 21 Apr 2010, Avi Kivity wrote: > >> On 04/21/2010 09:14 PM, Gerhard Wiesinger wrote: >>> >>> Can you explain which code files/functions of KVM is involved in >>> handling VGA memory window and page switching through the port write >>> to the VGA window register (or is that part handled through QEMU), >>> so a little bit architecture explaination would be nice? >> >> qemu hw/vga.c and hw/cirrus_vga.c. Boring functions like >> vbe_ioport_write_data() and vga_ioport_write(). >> > > Yes, I was already in that code part and that are very simple > functions as already explained and are therefore in QEMU only very > fast. But I ment: How is the calling path from KVM guest OS to > hw/vga.c for memory and I/O accesses, and which parts are done in > hardware directly (to understand the speed gap and maybe to find a > solution)? The speed gap is mostly due to hardware constraints (it takes ~2000 cycles for an exit from guest mode, plus we need to switch a few msrs to get to userspace). See vmx_vcpu_run(), the vmresume instruction is where an exit starts. > >>> >>> BTW: In which KVM code parts is decided where "direct code" or an >>> "emulated device code" is used? >>> >> >> Same place. Look for calls to cpu_register_physical_memory(). If >> the last argument was obtained by a call to cpu_register_io_memory(), >> then all writes trap. Otherwise, it was obtained by qemu_ram_alloc() >> and writes will not trap (except the first write to a page in a 30ms >> window, used to note that the page is dirty and needs redrawing). > > Ok, that finally ends in: > cpu_register_physical_memory_offset() > ... > // 0.12.3 > if (kvm_enabled()) > kvm_set_phys_mem(start_addr, size, phys_offset); > // KVM > cpu_notify_set_memory(start_addr, size, phys_offset); > ... > > I/O is always done through: > cpu_register_io_memory => cpu_register_io_memory_fixed > cpu_register_io_memory_fixed() > ... > No call to KVM? kvm_set_phys_mem() is a call to kvm. > ... > > Where is the trap from KVM to QEMU? See kvm_cpu_exec(). -- error compiling committee.c: too many arguments to function