From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R38lO-00057j-Ic for qemu-devel@nongnu.org; Mon, 12 Sep 2011 11:49:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R38lF-00029l-Uj for qemu-devel@nongnu.org; Mon, 12 Sep 2011 11:49:38 -0400 Received: from goliath.siemens.de ([192.35.17.28]:17360) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R38lE-00028i-Sh for qemu-devel@nongnu.org; Mon, 12 Sep 2011 11:49:29 -0400 Message-ID: <4E6E2A06.8010900@siemens.com> Date: Mon, 12 Sep 2011 17:49:26 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <3d9d904a1e4939a147f8954c9e0d4cdaf3d44c31.1314033132.git.jan.kiszka@siemens.com> <4E6E2329.9050109@suse.de> <4E6E2631.4060300@siemens.com> <4E6E28FD.7070907@web.de> In-Reply-To: <4E6E28FD.7070907@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Avi Kivity , Anthony Liguori , Gerd Hoffmann , Alexander Graf , qemu-devel On 2011-09-12 17:45, Andreas F=E4rber wrote: > Am 12.09.2011 17:33, schrieb Jan Kiszka: >> On 2011-09-12 17:20, Alexander Graf wrote: >>> Jan Kiszka wrote: >>>> Most VGA memory access modes require MMIO handling as they demand we= ird >>>> logic to get a byte from or into the video RAM. However, there is on= e >>>> exception: chain 4 mode with all memory planes enabled for writing. = This >>>> mode actually allows lineary mapping, which can then be combined wit= h >>>> dirty logging to accelerate KVM. >>>> >>>> This patch accelerates specifically VBE accesses like they are used = by >>>> grub in graphical mode. Not only the standard VGA adapter benefits f= rom >>>> this, also vmware and spice in VGA mode. >>>> >>>> CC: Gerd Hoffmann >>>> CC: Avi Kivity >>>> Signed-off-by: Jan Kiszka >>>> =20 >>> [...] >>> >>>> +static void vga_update_memory_access(VGACommonState *s) >>>> +{ >>>> + MemoryRegion *region, *old_region =3D s->chain4_alias; >>>> + target_phys_addr_t base, offset, size; >>>> + >>>> + s->chain4_alias =3D NULL; >>>> + >>>> + if ((s->sr[0x02] & 0xf) =3D=3D 0xf && s->sr[0x04] & 0x08) { >>>> + offset =3D 0; >>>> + switch ((s->gr[6] >> 2) & 3) { >>>> + case 0: >>>> + base =3D 0xa0000; >>>> + size =3D 0x20000; >>>> + break; >>>> + case 1: >>>> + base =3D 0xa0000; >>>> + size =3D 0x10000; >>>> + offset =3D s->bank_offset; >>>> + break; >>>> + case 2: >>>> + base =3D 0xb0000; >>>> + size =3D 0x8000; >>>> + break; >>>> + case 3: >>>> + base =3D 0xb8000; >>>> + size =3D 0x8000; >>>> + break; >>>> + } >>>> + region =3D g_malloc(sizeof(*region)); >>>> + memory_region_init_alias(region, "vga.chain4", &s->vram, of= fset, size); >>>> + memory_region_add_subregion_overlap(s->legacy_address_space= , base, >>>> + region, 2); >>>> =20 >>> This one eventually gives me the following in info mtree with -M g3be= ige >>> on qemu-system-ppc: >>> >>> (qemu) info mtree >>> memory >>> system addr 00000000 off 00000000 size 7fffffffffffffff >>> -vga.chain4 addr 000a0000 off 00000000 size 10000 >>> -macio addr 80880000 off 00000000 size 80000 >>> --macio-nvram addr 00060000 off 00000000 size 20000 >>> --pmac-ide addr 00020000 off 00000000 size 1000 >>> --cuda addr 00016000 off 00000000 size 2000 >>> --escc-bar addr 00013000 off 00000000 size 40 >>> --dbdma addr 00008000 off 00000000 size 1000 >>> --heathrow-pic addr 00000000 off 00000000 size 1000 >>> -vga.rom addr 80800000 off 00000000 size 10000 >>> -vga.vram addr 80000000 off 00000000 size 800000 >>> -vga-lowmem addr 800a0000 off 00000000 size 20000 >>> -escc addr 80013000 off 00000000 size 40 >>> -isa-mmio addr fe000000 off 00000000 size 200000 >>> I/O >>> io addr 00000000 off 00000000 size 10000 >>> -cmd646-bmdma addr 00000700 off 00000000 size 10 >>> --cmd646-bmdma-ioport addr 0000000c off 00000000 size 4 >>> --cmd646-bmdma-bus addr 00000008 off 00000000 size 4 >>> --cmd646-bmdma-ioport addr 00000004 off 00000000 size 4 >>> --cmd646-bmdma-bus addr 00000000 off 00000000 size 4 >>> -cmd646-cmd addr 00000680 off 00000000 size 4 >>> -cmd646-data addr 00000600 off 00000000 size 8 >>> -cmd646-cmd addr 00000580 off 00000000 size 4 >>> -cmd646-data addr 00000500 off 00000000 size 8 >>> -ne2000 addr 00000400 off 00000000 size 100 >>> >>> This ends up overmapping 0xa0000, effectively overwriting kernel data. >>> If I #if 0 the offending chunk out, everything is fine. I would assum= e >>> that chain4 really needs to be inside of lowmem? No idea about VGA, b= ut >>> I'm sure you know what's going on :). >> Does this help? >> >> diff --git a/hw/vga.c b/hw/vga.c >> index 125fb29..0a0c5a6 100644 >> --- a/hw/vga.c >> +++ b/hw/vga.c >> @@ -181,6 +181,7 @@ static void vga_update_memory_access(VGACommonStat= e *s) >> size =3D 0x8000; >> break; >> } >> + base +=3D isa_mem_base; >> region =3D g_malloc(sizeof(*region)); >> memory_region_init_alias(region, "vga.chain4", &s->vram, offs= et, size); >> memory_region_add_subregion_overlap(s->legacy_address_space, = base, >=20 > No longer oopses, but the screen looks chaotic now (black bar at bottom= , > part of contents at top etc.). Does this PPC machine map the ISA range and forward VGA accesses to the adapter in general? Jan --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux