From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Question about removing memslots Date: Thu, 29 Mar 2012 11:36:59 +0200 Message-ID: <4F742D3B.2060904@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> <4F72ED38.5000007@redhat.com> <1332968658.2882.108.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]:11643 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751796Ab2C2JhH (ORCPT ); Thu, 29 Mar 2012 05:37:07 -0400 In-Reply-To: <1332968658.2882.108.camel@pasglop> Sender: kvm-owner@vger.kernel.org List-ID: On 03/28/2012 11:04 PM, Benjamin Herrenschmidt wrote: > On Wed, 2012-03-28 at 12:51 +0200, Avi Kivity wrote: > > > 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): > >=20 > > 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= -expand > > BitBLTs. This frees the linear address apertures for other, concurr= ent > > accesses. If this bit is =E2=80=980=E2=80=99, the CL-GD546X uses th= e linear 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 i= n > > 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. > >=20 > > If a system-to-screen BitBLT requiring data is not active, writes t= o the > > second window complete in the minimum time and the data is discarde= d. > > Writes to the first window are ignored by the BitBLT engine (but ar= e > > taken as direct writes to the frame buffer). > >=20 > > If this bit is =E2=80=980=E2=80=99, system-to-screen BitBLTs use th= e first 16-Mbyte > > window (compatible with CL-GD543X/=E2=80=994X). > >=20 > > But it looks like this refers to 546x, even though I found it in th= e > > 5446 manual. > > Right. The first option uses legacy VGA memory which I don't always h= ave > access to so that's not really an option for cirrusfb in general (in > fact I made it not use IO either, it's doing full MMIO for configurin= g > the CRTCs as well). > > I could (I have patches to do so) open a ISA/VGA memory window on the > bridge, in fact I need that for the X driver to work for other reason= s, > but I'd rather not have cirrusfb deal with that. > > The funny thing here is we have "clean" APIs to let userspace map (wh= en > available) and access legacy VGA memory & IO ports, but we don't have= a > good in-kernel API to do the same thing :-) On x86 things are somewha= t > easy because it's just all hard coded and there's really only one PCI= do > main but on anything else it's a mess. > > In any case, X seems to avoid it, maybe nobody does color expansion > nowadays (I suppose modern desktops don't, maybe using ancient X apps > might trigger that path). So no biggie. I'll have to fix KVM powerpc > dealing with memslot changes anyways. > > Thanks for your help, > As a workaround you can use -vga std or -vga qxl. The latter will work even better when we have a kernel driver. --=20 error compiling committee.c: too many arguments to function