Comment 40 for bug 1448985

Finally with a little help on debugging unity, I think I see what is going on. The obvious part seemed to be that compiz seems to fail starting. Which turns out to be LLVM-pipe bailing with an obscure error message:

LLVM ERROR: Do not know how to split the result of this operator!

This made me think about the emulated CPU, even more because Xen HVM guests do work with the i386 isos. And really this is the actual problem! So one quick work-around is to force qemu to use a different CPU type. In my test I used the Wily i386 iso and changed the CPU type from the default (QEMU Virtual CPU v2.0.0) into core2duo. And suddenly the live session works.

So next, what is the difference. Beside of name, model, and stepping, it seems the cpuid flags:

Core(TM)2 Duo CPU (emulated) QEMU Virtual CPU v2.0.0
model 15 model 6
stepping 11 stepping 3
cpuid level 10 cpuid level 4

ore(TM)2 Duo CPU (emulated) QEMU Virtual CPU v2.0.0
model 15 model 6
stepping 11 stepping 3
cpuid level 10 cpuid level 4
 --> fpu vme de pse tsc msr pae mce
 fpu de pse tsc msr pae mce <--
 --> cx8 apic sep mtrr pge mca cmov
 cx8 apic sep mtrr pge mca cmov <--
 --> pat pse36 clflush mmx fxsr sse
     pse36 clflush mmx fxsr sse <--
 --> sse2 ss syscall nx lm
 sse2 syscall nx lm <--
 --> constant_tsc pni vmx ssse3
                         pni vmx <--
 --> cx16 x2apic hypervisor
 cx16 x2apic popcnt hypervisor <--
 --> lahf_lm vnmi ept
 lahf_lm vnmi ept <--

So QEMU CPU misses: vme, pat, ss, constant_tsc, and ssse3 but has popcnt. A different host running Xen was also missing ss, constant_tsc, ssse3, and popct. But it had vme and pat and was working with the i386 iso.
That sounds a bit like either vme or pat missing could cause the i386 build of llvmpipe to fail while the exact same cpuid configuration works with the amd64 version of llvmpipe.