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 -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
