Re: Question about removing memslots

[Avi Kivity <avi@redhat.com>]

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. 
> > Newer chips do allow a workaround (GR31 bit 6):
> > 
> > 6 System Source Location (Revision A): If this bit is ‘1’, the CL-GD546X
> > responds to write accesses at 000BC000h–000BFFFFh for color-expand
> > BitBLTs. This frees the linear address apertures for other, concurrent
> > accesses. If this bit is ‘0’, the CL-GD546X uses the linear aperture for
> > BitBLTs (compatible with CL-GD543X/’4X).
> >   System Source Location (Revision B): If this bit is ‘1’,
> > 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 the
> > 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 ‘0’, system-to-screen BitBLTs use the first 16-Mbyte
> > window (compatible with CL-GD543X/’4X).
> > 
> > But it looks like this refers to 546x, even though I found it in the
> > 5446 manual.
>
> Right. The first option uses legacy VGA memory which I don't always have
> 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 configuring
> 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 reasons,
> but I'd rather not have cirrusfb deal with that.
>
> The funny thing here is we have "clean" APIs to let userspace map (when
> 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 somewhat
> 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.

-- 
error compiling committee.c: too many arguments to function