From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kx40g-0002rY-Nc for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:18:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kx40f-0002o8-6k for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:18:42 -0500 Received: from [199.232.76.173] (port=54651 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kx40f-0002nr-3g for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:18:41 -0500 Received: from yx-out-1718.google.com ([74.125.44.154]:64924) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kx40b-0003ap-7y for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:18:37 -0500 Received: by yx-out-1718.google.com with SMTP id 3so923209yxi.82 for ; Mon, 03 Nov 2008 10:18:35 -0800 (PST) Message-ID: <5d6222a80811031018w4a84e966t50f25e7c4ddb34f2@mail.gmail.com> Date: Mon, 3 Nov 2008 16:18:35 -0200 From: "Glauber Costa" Subject: Re: [Qemu-devel] vga optmization In-Reply-To: <490F3F64.30204@bellard.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081103173111.GC30410@poweredge.glommer> <490F3F64.30204@bellard.org> 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 Cc: Glauber Costa , aliguori@us.ibm.com On Mon, Nov 3, 2008 at 4:13 PM, Fabrice Bellard wrote: > 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 > > Why don't you modify the lower level QEMU dirty bits handling functions > to be consistent with the KVM dirty bits ? By doing that you can avoid > patching the device drivers and have smaller code. The fact that KVM use > physical memory addresses is not a problem if you can convert the ram > addresses to physical memory addresses (in most cases there is only one > physical address corresponding to one RAM address). Not here. We have to map vga linear frame buffer as RAM. So the option is to always do that. That's pretty much the only device specific thing we're doing here About physical memory, exactly: code in kvm userspace does it a little bit differently, and it is _this_ code that does it the qemu way. So it seems we're in agreement. -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."