I tried swapping out the L1 guest (the qemu process), and L0 had the BUG
detailed below.

To replicate this I did:
1. Ran L1 and L2 (single vcpu in each), and a "make -j3" loop in L2.
2. "kill -stop" the qemu process in L0.
3. Note that the qemu process has a lot of resident memory (in "ps aux")
4. Take up memory with the command 'perl -e '"aaaaa"x1000090000;' - adding a's
as necessary until the qemu process is all swapped out (almost 0 resident
memory)
5. Resume the qemu process with "kill -cont".

I only saw this bug in May 2011, so it needs verification that it still exists. 

The BUG I got in L0's logs: 

BUG: unable to handle kernel paging request at ffff87ffffffffff
IP: [<ffffffffa3e09aa9>] __direct_map+0x10c/0x1cf [kvm]
PGD 0 
Oops: 0000 [#1] SMP 
last sysfs file: /sys/devices/system/cpu/cpu9/cpufreq/scaling_governor
CPU 7 
Modules linked in: kvm_intel kvm [last unloaded: kvm]

Pid: 18584, comm: qemu-system-x86 Not tainted
2.6.39-rc2nested-78624-g40f4a24-dirty #240 IBM IBM System x -[794692G]-/49Y6498 
RIP: 0010:[<ffffffffa3e09aa9>]  [<ffffffffa3e09aa9>] __direct_map+0x10c/0x1cf
[kvm]
RSP: 0018:ffff880175071ae8  EFLAGS: 00010206
RAX: ffff87ffffffffff RBX: ffff880173e34040 RCX: 0000000000000027
RDX: ffff87ffffffffff RSI: ffff880173e34040 RDI: 0000000000000004
RBP: ffff880175071b98 R08: 0000000000000000 R09: 0000000000044c51
R10: ffffffffa3e0a23c R11: ffffea0000000000 R12: 0000000000044c51
R13: 0000000000000001 R14: 000ffffffffff000 R15: 0000000000000000
FS:  00007fada5fc3910(0000) GS:ffff88017fce0000(0000) knlGS:0000000000000000CS:
 0010 DS: 002b ES: 002b CR0: 000000008005003b
CR2: ffff87ffffffffff CR3: 0000000173aaf000 CR4: 00000000000026f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process qemu-system-x86 (pid: 18584, threadinfo ffff880175070000, task
ffff880179017040)
Stack:
 0000000200044c00 000000000000058c ffff880173e34040 ffff880179017040
 0000000000000246 0000000000000001 0000000044c51ff8 0000000000000000
 ffff880175071b68 0000000000000246 0000000044c51000 ffffffffffffffff
Call Trace:
 [<ffffffffa3e0a2a0>] tdp_page_fault+0x16a/0x1ad [kvm]
 [<ffffffffa3e07f26>] kvm_mmu_page_fault+0x24/0x81 [kvm]
 [<ffffffffa4a323c8>] handle_ept_violation+0xe3/0xec [kvm_intel]
 [<ffffffffa4a36d5b>] vmx_handle_exit+0x5f8/0x627 [kvm_intel]
 [<ffffffffa3e01a41>] kvm_arch_vcpu_ioctl_run+0xa84/0xdfc [kvm]
 [<ffffffffa3e019ad>] ? kvm_arch_vcpu_ioctl_run+0x9f0/0xdfc [kvm]
 [<ffffffffa3e006ee>] ? kvm_arch_vcpu_load+0x89/0x107 [kvm]
 [<ffffffffa3df6605>] kvm_vcpu_ioctl+0x113/0x4e6 [kvm]
 [<ffffffff81056f2a>] ? __lock_acquire+0x8b7/0x928
 [<ffffffff8104adf1>] ? up_read+0x1e/0x35
 [<ffffffff8101f963>] ? do_page_fault+0x33b/0x37a
 [<ffffffff810ae641>] do_vfs_ioctl+0x482/0x4d1
 [<ffffffff810a13d4>] ? fget_light+0xf0/0x102
 [<ffffffff810a1346>] ? fget_light+0x62/0x102
 [<ffffffff810ae6d2>] sys_ioctl+0x42/0x65
 [<ffffffff815169fb>] system_call_fastpath+0x16/0x1b
Code: 8b 74 10 10 8a 46 28 83 e0 0f ff c8 7f 0b 4c 89 e2 48 89 df e8 1c fd ff
ff ff 83 40 01 00 00 e9 b5 00 00 00 4c 8b 05 a7 5f 01 00 <4c> 39 00 0f 85 83 00
00 00 ff cf 48 8b 55 a0 8d 0c ff 48 89 d6 
RIP  [<ffffffffa3e09aa9>] __direct_map+0x10c/0x1cf [kvm]
 RSP <ffff880175071ae8>
CR2: ffff87ffffffffff
---[ end trace 0fc73878e09048e2 ]---