Comment 25 for bug 1208455

Trying to summarize my testing so far:

Host: saucy 64bit, 1rst level saucy 32bit, 2nd level saucy 32bit:
- 2nd level guest did not start when using qemu-system-x86_64:
  - This may be some regression or feature, not sure, yet.
- Using qemu only (defaulting to same arch) the 2nd level guest starts:
  - I saw many NMI (21 / 31) messages which looks not good.
  - One run completed, the other caused a double fault in 2nd level.

Host: Saucy 64bit, 1rst level saucy 64bit, 2nd level saucy 32bit:
- Not ultimately required, but also using qemu (not qemu-system-x86_64).
- Works much better but doing many loops at some point there is a double
   fault too.

Host: Quantal 64bit, 1rst level saucy 32bit, 2nd level saucy 32bit:
- Had the lockups when using qemu-system-x86_64.
- Currently completed 3 runs (needs more time) with qemu only call.

Host: Quantal 64bit, 1rst level saucy 64bit, 2nd level saucy 32bit:
- With qemu only call now completed run 7.

This is not conclusive yet as I need more runs, but Quantal as host seems more stable than Saucy. The question is whether this is also true for Precise as host (unfortunately my test HW is too new, so its wired network is not supported back in Precise). James, maybe you want to try that. One critical change seems to be the use of qemu instead of qemu-system-x86_64. I am not sure whether starting a 64bit system with hardware acceleration from a 32bit system is something that is supposed to work. Well the emulated cpu likely claims 64bit capability but then I am not sure whether that combo is so well tested with respect to other interfaces.