From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kx4T1-0004aN-Ig for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:47:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kx4Sz-0004a6-59 for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:47:58 -0500 Received: from [199.232.76.173] (port=54009 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kx4Sy-0004a3-Vc for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:47:57 -0500 Received: from wf-out-1314.google.com ([209.85.200.171]:16825) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kx4Sy-0000Xp-8x for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:47:56 -0500 Received: by wf-out-1314.google.com with SMTP id 27so2682417wfd.4 for ; Mon, 03 Nov 2008 10:47:54 -0800 (PST) Message-ID: <5d6222a80811031047r5489a008r8cc78b481b73978d@mail.gmail.com> Date: Mon, 3 Nov 2008 16:47:54 -0200 From: "Glauber Costa" Subject: Re: [Qemu-devel] vga optmization In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081103173111.GC30410@poweredge.glommer> <5d6222a80811031014r19342d1ex8753d0c6368acc75@mail.gmail.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 4:41 PM, Blue Swirl wrote: > On 11/3/08, Glauber Costa wrote: >> On Mon, Nov 3, 2008 at 4:03 PM, Blue Swirl wrote: >> > On 11/3/08, 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 >> > >> > The patch does not apply, because of the kvm files. What patches do I >> > need to apply first? I'd like to see how does the optimization apply >> > to TCX. >> >> >> Yes, you are missing kvm patches some time ago, which he plans to merge. >> >> >> > This also may mean that some of my comments below can be invalid. >> > >> >> +void set_vram_mapping(target_phys_addr_t begin, target_phys_addr_t end, ram_addr_t target) >> > >> > No "static"? >> >> thanks, will update. >> >> >> > >> >> +{ >> >> + /* align begin and end address */ >> >> + begin = begin & TARGET_PAGE_MASK; >> >> + end = begin + VGA_RAM_SIZE; >> >> + end = (end + TARGET_PAGE_SIZE -1 ) & TARGET_PAGE_MASK; >> > >> > This will fail if "end" is at the last page of the memory. >> >> >> How so? I don't think it's possible for the addr 0xsomething0001 to be >> valid, but 0x(something+1)000 to be not. > > 0xfffff001 + 0xfff = 0 (wrapped), then masking still gives 0. oh, you're talking about the last page in the possible address space. In that case I agree, but I believe we're not expecting vga to ever be there. > >> > >> >> + uint32_t vga_io_memory; \ >> > >> > cpu_register_io_memory() returns an "int". >> >> >> can it possibly be negative? >> that said, of course I can change it for consistency, but I'd like to >> understand it more > > In case of error it could be negative but I'm only thinking about consistency. fair. I'll update it. > > -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."