On 27.06.2012, at 23:39, Benjamin Herrenschmidt wrote: > On Wed, 2012-06-27 at 14:08 +0200, Alexander Graf wrote: >> Ben, mind to push a working SLOF, we we can just enable all of it in >> one go and don't have to commit #if 0'ed code? >> >> Rest looks reasonable to me. > > Sure, SLOF was gated by the memop patch but we can push it now. However > I'd rather leave that #if 0 for now for cirrus... > > There are several issues with cirrus at the moment. Off the top of my > head: > > - The Xorg driver has bugs with physical addresses > 32-bit (even when > compiled 64-bit). I had a patch floating around, I need to refresh it > and get it merged. > > - There is another issue with the way it accesses legacy VGA space > which should be routed by the kernel to a bit of shmem but isn't, we > need to add support for a VGA hole to qemu (if we didn't already, I > don't remember now, I'll check that later). > > - cirrusfb in the kernel will explode due to various bugs in it > (basically assumes that on powerpc it's a prep machine and does horrible > things with resources). Even with that fixed we still have a problem > with color expansion > > - color expansion works by constantly replacing the memory region in > qemu that covers the frame buffer, flipping it between a direct mapping > of the fb vs. emulated registers. This triggers races & problems in our > kvm implementation. We need to fix them but we haven't yet. > > So overall, let's keep cirrus off in that code path. It's still possible > to manually enable it with -device for development/debugging purposes.
It shouldn't be an #if 0 but an if (cirrus) hw_abort() then though. Otherwise we'd just silently ignore the option. Alex