From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kx3bU-0001z6-Sf for qemu-devel@nongnu.org; Mon, 03 Nov 2008 12:52:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kx3bU-0001yu-G4 for qemu-devel@nongnu.org; Mon, 03 Nov 2008 12:52:40 -0500 Received: from [199.232.76.173] (port=40421 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kx3bU-0001yr-Ad for qemu-devel@nongnu.org; Mon, 03 Nov 2008 12:52:40 -0500 Received: from yx-out-1718.google.com ([74.125.44.154]:59635) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kx3bU-0007j7-1f for qemu-devel@nongnu.org; Mon, 03 Nov 2008 12:52:40 -0500 Received: by yx-out-1718.google.com with SMTP id 3so917919yxi.82 for ; Mon, 03 Nov 2008 09:52:38 -0800 (PST) Message-ID: <5d6222a80811030952r5bfa67end7aa0ffe684d9abf@mail.gmail.com> Date: Mon, 3 Nov 2008 15:52:37 -0200 From: "Glauber Costa" Subject: Re: [Qemu-devel] vga optmization In-Reply-To: <490F3838.8010401@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081103173111.GC30410@poweredge.glommer> <490F3838.8010401@eu.citrix.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Mon, Nov 3, 2008 at 3:43 PM, Stefano Stabellini wrote: > Can we try to avoid any if (kvm_enabled()) in the vga code and use some > kind of more generic hook instead? > Xen has some very similar changes to the vga code, it would be nice to > merge them as well. Yes, we could. But then we'd need to have qemu to view memory as slots. It's worthy, but long term. By the way, posting those xen changes would be awesome. If we both can avoid using hv-specific hooks (which I did: there's only one left), and so do you, I'm sure we can come up with something very nice in the end of the day. > > Glauber Costa wrote: > >> Hi guys, >> >> this is a port of current kvm vga memory optimization to our new >> infrastructure proposed by anthony. It's goal is to use as few >> kvm specific hooks as possible. In fact, the only one I'm relying >> on is enabling/disabling of logging. The rest, is pretty much general. >> >> We map the linear frame buffer area as RAM, and then use dirty tracking >> to decide whether or not to update it. To be consistent with qemu, >> this version, differently from upstream kvm, tracks memory based on its >> physical address, represented by vram_offset, instead of vram_ptr, or >> any other construct. >> >> Let me know what you think >> >> > > > > > -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."