From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Question about removing memslots Date: Wed, 28 Mar 2012 12:51:36 +0200 Message-ID: <4F72ED38.5000007@redhat.com> References: <1332919486.2882.88.camel@pasglop> <4F72DBE2.6060909@redhat.com> <1332928770.2882.98.camel@pasglop> <4F72E274.2090007@redhat.com> <1332929849.2882.101.camel@pasglop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org, Alexander Graf , kvm-ppc@vger.kernel.org, Scott Wood , Alex Williamson To: Benjamin Herrenschmidt Return-path: Received: from mx1.redhat.com ([209.132.183.28]:25999 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753949Ab2C1Kvo (ORCPT ); Wed, 28 Mar 2012 06:51:44 -0400 In-Reply-To: <1332929849.2882.101.camel@pasglop> Sender: kvm-owner@vger.kernel.org List-ID: On 03/28/2012 12:17 PM, Benjamin Herrenschmidt wrote: > On Wed, 2012-03-28 at 12:05 +0200, Avi Kivity wrote: > > > That's strange, the cirrus BAR allows the framebuffer and bitblt re= gion > > to coexist: > >=20 > > 0000000000000000-7ffffffffffffffe (prio 0, RW): pci > > 00000000000a0000-00000000000bffff (prio 1, RW): cirrus-lowmem-con= tainer > > 00000000000a0000-00000000000a7fff (prio 1, RW): alias vga.bank0 > > @vga.vram 0000000000000000-0000000000007fff > > 00000000000a0000-00000000000bffff (prio 0, RW): cirrus-low-memo= ry > > 00000000000a8000-00000000000affff (prio 1, RW): alias vga.bank1 > > @vga.vram > >=20 > > ^ those are continuously flipped when running 16-bit software > >=20 > > 0000000000008000-000000000000ffff > > 00000000000c0000-00000000000dffff (prio 1, RW): pc.rom > > 00000000000e0000-00000000000fffff (prio 1, R-): isa-bios > > 00000000fc000000-00000000fdffffff (prio 1, RW): cirrus-pci-bar0 > > 00000000fc000000-00000000fc7fffff (prio 1, RW): vga.vram > > 00000000fc000000-00000000fc7fffff (prio 0, RW): cirrus-linear-i= o > > 00000000fd000000-00000000fd3fffff (prio 0, RW): cirrus-bitblt-m= mio > >=20 > > ^ the cirrus BAR, write to 0xfc000000 and you hit vga.vram, write t= o > > 0xfd000000 and you trigger a bitblt. > >=20 > > 00000000feba0000-00000000febbffff (prio 1, RW): e1000-mmio > > 00000000febf0000-00000000febf0fff (prio 1, RW): cirrus-mmio > >=20 > > A guest driver problem perhaps? > > Quite possibly, I'm not familiar with the cirrus HW. The trigger is a= n > MMIO register write done by cirrusfb, which causes > cirrus_update_memory_access() to switch the BAR to emulation as a res= ult > of this becoming true: > > s->cirrus_srcptr !=3D s->cirrus_srcptr_end > > I haven't had a chance to dig further today (I'm home now), I can hav= e a > look tomorrow. > Ah, then it's not a guest problem, it's how the chip was designed.=20 Newer chips do allow a workaround (GR31 bit 6): 6 System Source Location (Revision A): If this bit is =E2=80=981=E2=80=99= , the CL-GD546X responds to write accesses at 000BC000h=E2=80=93000BFFFFh for color-exp= and BitBLTs. This frees the linear address apertures for other, concurrent accesses. If this bit is =E2=80=980=E2=80=99, the CL-GD546X uses the li= near aperture for BitBLTs (compatible with CL-GD543X/=E2=80=994X). System Source Location (Revision B): If this bit is =E2=80=981=E2=80=99= , system-to-screen BitBLTs use the second 16-Mbyte window specified in PCI10. This allows direct frame buffer accesses in the first window to be mixed with system-to-screen writes in the second window without restrictions. If a system-to-screen BitBLT requiring data is not active, writes to th= e second window complete in the minimum time and the data is discarded. Writes to the first window are ignored by the BitBLT engine (but are taken as direct writes to the frame buffer). If this bit is =E2=80=980=E2=80=99, system-to-screen BitBLTs use the fi= rst 16-Mbyte window (compatible with CL-GD543X/=E2=80=994X). But it looks like this refers to 546x, even though I found it in the 5446 manual. --=20 error compiling committee.c: too many arguments to function