From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Kx3mJ-0001GS-TY
	for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:03:51 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Kx3mG-0001Ao-8s
	for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:03:51 -0500
Received: from [199.232.76.173] (port=49144 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Kx3mG-0001Ab-3m
	for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:03:48 -0500
Received: from rn-out-0910.google.com ([64.233.170.184]:57667)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1Kx3mF-00016y-DL
	for qemu-devel@nongnu.org; Mon, 03 Nov 2008 13:03:47 -0500
Received: by rn-out-0910.google.com with SMTP id m61so1956274rnd.8
	for <qemu-devel@nongnu.org>; Mon, 03 Nov 2008 10:03:42 -0800 (PST)
Message-ID: <f43fc5580811031003i4eea1fb0pc93c5e45f807767e@mail.gmail.com>
Date: Mon, 3 Nov 2008 20:03:41 +0200
From: "Blue Swirl" <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] vga optmization
In-Reply-To: <20081103173111.GC30410@poweredge.glommer>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20081103173111.GC30410@poweredge.glommer>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

On 11/3/08, Glauber Costa <glommer@redhat.com> 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.

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"?

>  +{
>  +    /* 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.

>  +void unset_vram_mapping(target_phys_addr_t begin, target_phys_addr_t end)

No "static"?

>  +{
>  +    /* align begin and end address */
>  +    end = begin + VGA_RAM_SIZE;
>  +    begin = begin & TARGET_PAGE_MASK;
>  +    end = (end + TARGET_PAGE_SIZE -1 ) & TARGET_PAGE_MASK;

This will fail if "end" is at the last page of the memory.

>  +void unmap_linear_vram(CirrusVGAState *s)

No "static"?

>  +    uint32_t vga_io_memory;                                             \

cpu_register_io_memory() returns an "int".