* Guest memory backed by PCI BAR (x86)
@ 2015-03-25 15:56 Nate Case
2015-03-26 14:02 ` Paolo Bonzini
0 siblings, 1 reply; 10+ messages in thread
From: Nate Case @ 2015-03-25 15:56 UTC (permalink / raw)
To: kvm
Hello,
I have an unusual goal of presenting SDRAM located on a real PCIe device
(exposed via BAR) to a guest as normal memory. Eventually I'd like to
split up guest memory between PCI memory and host memory as different
NUMA nodes to optimize performance; but for now I'm focusing on just
getting the guest to use memory over PCIe entirely, ignoring the
awful performance.
My first attempt was to modify qemu's "-mem-path" parameter to also
support mmap()able files in addition to hugetlbfs paths. This was
fairly straightforward, and using a tmpfs file (backed by host SDRAM)
as guest RAM appears to work fine.
I was hoping I could then use a PCI sysfs resource file instead of a
tmpfs file (i.e., /sys/bus/pci/devices/dddd:bb:ss.f/resourceN) to
achieve the desired effect. But I haven't been able to get Linux or
memtest86+ to boot with this arrangement. It only boots when KVM
acceleration is disabled.
When KVM acceleration is enabled, SeaBIOS seems to function fine
running out of PCI memory space, but booting the OS resets.
Specifically, the following happens (I'll stick with the memtest86+
5.01 test case for simplicity):
setup.S of memtest:
---[snip]---
/*
* Note that the short jump isn't strictly needed, althought there are
* reasons why it might be a good idea. It won't hurt in any case.
*/
movw $0x0001, %ax # protected mode (PE) bit
lmsw %ax # This is it#
jmp flush_instr
flush_instr:
movw $KERNEL_DS, %ax
movw %ax, %ds
movw %ax, %es
movw %ax, %ss <---- broken here
movw %ax, %fs
movw %ax, %gs
---[snip]---
In this portion that's attempting to enter protected mode, the
"movw %ax, %ss" instruction execution results in the guest resetting.
gdb shows that after stepping through this instruction, CS:IP points
to F000:E05B (entry_post within SeaBIOS).
I'm new to KVM, so I'm hoping someone could provide some guidance on
what might be wrong, what you'd recommend to get this working, or how
I might debug this better.
I'm using qemu 2.2.0 and an EL6 kernel (2.6.32-358.23.2.el6.x86_64).
Thanks,
Nate
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Guest memory backed by PCI BAR (x86) 2015-03-25 15:56 Guest memory backed by PCI BAR (x86) Nate Case @ 2015-03-26 14:02 ` Paolo Bonzini 2015-03-26 16:01 ` Nate Case 0 siblings, 1 reply; 10+ messages in thread From: Paolo Bonzini @ 2015-03-26 14:02 UTC (permalink / raw) To: Nate Case, kvm On 25/03/2015 16:56, Nate Case wrote: > I was hoping I could then use a PCI sysfs resource file instead of a > tmpfs file (i.e., /sys/bus/pci/devices/dddd:bb:ss.f/resourceN) to > achieve the desired effect. But I haven't been able to get Linux or > memtest86+ to boot with this arrangement. It only boots when KVM > acceleration is disabled. > > When KVM acceleration is enabled, SeaBIOS seems to function fine > running out of PCI memory space, but booting the OS resets. > Specifically, the following happens (I'll stick with the memtest86+ > 5.01 test case for simplicity): Hi, please include a trace file of the failure, obtained using "trace-cmd record -e kvm/* -e kvmmmu/*". Thanks, Paolo ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Guest memory backed by PCI BAR (x86) 2015-03-26 14:02 ` Paolo Bonzini @ 2015-03-26 16:01 ` Nate Case 2015-03-26 16:07 ` Paolo Bonzini 0 siblings, 1 reply; 10+ messages in thread From: Nate Case @ 2015-03-26 16:01 UTC (permalink / raw) To: Paolo Bonzini; +Cc: kvm > > When KVM acceleration is enabled, SeaBIOS seems to function fine > > running out of PCI memory space, but booting the OS resets. > > Specifically, the following happens (I'll stick with the memtest86+ > > 5.01 test case for simplicity): > > > please include a trace file of the failure, obtained using "trace-cmd > record -e kvm/* -e kvmmmu/*". Paolo, The trace file is available here: http://oss.xes-inc.com/xtmp/trace-pcimem-memtest86-reset.dat.gz Thanks, Nate ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Guest memory backed by PCI BAR (x86) 2015-03-26 16:01 ` Nate Case @ 2015-03-26 16:07 ` Paolo Bonzini 2015-03-26 16:34 ` Nate Case 0 siblings, 1 reply; 10+ messages in thread From: Paolo Bonzini @ 2015-03-26 16:07 UTC (permalink / raw) To: Nate Case; +Cc: kvm On 26/03/2015 17:01, Nate Case wrote: >>> When KVM acceleration is enabled, SeaBIOS seems to function fine >>> running out of PCI memory space, but booting the OS resets. >>> Specifically, the following happens (I'll stick with the memtest86+ >>> 5.01 test case for simplicity): >> >> >> please include a trace file of the failure, obtained using "trace-cmd >> record -e kvm/* -e kvmmmu/*". > > Paolo, > > The trace file is available here: > > http://oss.xes-inc.com/xtmp/trace-pcimem-memtest86-reset.dat.gz Run QEMU with "-no-reboot -no-shutdown -monitor stdio". When it crashes, run "info registers" and then "x/70i 0", and email the output. Paolo ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Guest memory backed by PCI BAR (x86) 2015-03-26 16:07 ` Paolo Bonzini @ 2015-03-26 16:34 ` Nate Case 2015-03-26 16:40 ` Paolo Bonzini 0 siblings, 1 reply; 10+ messages in thread From: Nate Case @ 2015-03-26 16:34 UTC (permalink / raw) To: Paolo Bonzini; +Cc: kvm > > > > The trace file is available here: > > > > http://oss.xes-inc.com/xtmp/trace-pcimem-memtest86-reset.dat.gz > > Run QEMU with "-no-reboot -no-shutdown -monitor stdio". When it > crashes, run "info registers" and then "x/70i 0", and email the output. QEMU output: ---[snip]--- $ qemu-system-x86_64 -enable-kvm -name testVM6 -machine \ q35,accel=kvm,usb=off -cpu Haswell -m 256 -realtime mlock=off -smp \ 1,sockets=1,cores=1,threads=1 -boot order=d image.memtest -vga std \ -display vnc=${LAN_IP}:0 -mem-path \ /sys/bus/pci/devices/0000\:01:00.0/resource2_wc --mem-prealloc -cdrom \ memtest86+-5.01.iso -s -S -d cpu_reset,unimp,guest_errors,int,pcall \ -no-reboot -no-shutdown -monitor stdio QEMU 2.2.0 monitor - type 'help' for more information (qemu) CPU Reset (CPU 0) [[ trimmed initial reset with all zeroed registers ]] CPU Reset (CPU 0) EAX=00000000 EBX=00000000 ECX=00000000 EDX=000306c1 ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 0000ffff 00009300 CS =f000 ffff0000 0000ffff 00009b00 SS =0000 00000000 0000ffff 00009300 DS =0000 00000000 0000ffff 00009300 FS =0000 00000000 0000ffff 00009300 GS =0000 00000000 0000ffff 00009300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 00000000 0000ffff IDT= 00000000 0000ffff CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 CCS=00000000 CCD=00000000 CCO=DYNAMIC EFER=0000000000000000 FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 ---[snip]--- gdb output: ---[snip]--- real-mode-gdb$ info registers eax 0x18 24 ecx 0x2000 8192 edx 0x92 146 ebx 0x0 0 esp 0x800 0x800 ebp 0x1d0 0x1d0 esi 0x5a00 23040 edi 0x3ff4 16372 eip 0x58 0x58 eflags 0x10046 [ PF ZF RF ] cs 0x9020 36896 ss 0x9000 36864 ds 0x18 24 es 0x18 24 fs 0x9000 36864 gs 0x9000 36864 real-mode-gdb$ x/70i 0 0x0: push bx 0x1: inc WORD PTR [bx+si] 0x3: lock push bx 0x5: inc WORD PTR [bx+si] 0x7: lock ret 0x9: loop 0xb 0xb: lock push bx 0xd: inc WORD PTR [bx+si] 0xf: lock push bx 0x11: inc WORD PTR [bx+si] 0x13: lock push bx 0x15: inc WORD PTR [bx+si] 0x17: lock push bx 0x19: inc WORD PTR [bx+si] 0x1b: lock push bx 0x1d: inc WORD PTR [bx+si] 0x1f: lock movs WORD PTR es:[di],WORD PTR ds:[si] 0x21: inc BYTE PTR [bx+si] 0x23: lock xchg cx,bp 0x26: add al,dh 0x28: jmp 0xf9 0x2b: lock jmp 0xfd 0x2f: lock jmp 0x101 0x33: lock jmp 0x105 0x37: lock jmp 0x109 0x3b: lock jmp 0x10d 0x3f: lock mov dl,BYTE PTR [bx+si+0x0] 0x43: ror BYTE PTR [di-0x8],0x0 0x47: lock inc cx 0x49: clc 0x4a: add al,dh 0x4c: (bad) 0x4d: jcxz 0x4f 0x4f: lock cmp di,sp 0x52: add al,dh 0x54: pop cx 0x55: clc 0x56: add al,dh => 0x58: cs 0x59: call 0xf05c 0x5c: shr bh,cl 0x5e: add al,dh 0x60: add ax,0xcf 0x63: lock repnz out 0x0,al 0x67: lock outs dx,BYTE PTR ds:[si] 0x69: inc BYTE PTR [bx+si] 0x6b: lock push bx 0x6d: inc WORD PTR [bx+si] 0x6f: lock push bx 0x71: inc WORD PTR [bx+si] 0x73: lock push bx 0x75: inc WORD PTR [bx+si] 0x77: lock hlt 0x79: aas 0x7a: add BYTE PTR [bx+si-0x7a78],dl 0x7e: add al,al 0x80: push bx 0x81: inc WORD PTR [bx+si] 0x83: lock push bx 0x85: inc WORD PTR [bx+si] 0x87: lock push bx 0x89: inc WORD PTR [bx+si] 0x8b: lock push bx 0x8d: inc WORD PTR [bx+si] 0x8f: lock push bx 0x91: inc WORD PTR [bx+si] 0x93: lock push bx 0x95: inc WORD PTR [bx+si] 0x97: lock push bx 0x99: inc WORD PTR [bx+si] ---[snip]--- Thanks, Nate ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Guest memory backed by PCI BAR (x86) 2015-03-26 16:34 ` Nate Case @ 2015-03-26 16:40 ` Paolo Bonzini 2015-03-26 16:52 ` Nate Case 0 siblings, 1 reply; 10+ messages in thread From: Paolo Bonzini @ 2015-03-26 16:40 UTC (permalink / raw) To: Nate Case; +Cc: kvm On 26/03/2015 17:34, Nate Case wrote: > 0x52: add al,dh > 0x54: pop cx > 0x55: clc > 0x56: add al,dh > => 0x58: cs > 0x59: call 0xf05c > 0x5c: shr bh,cl > 0x5e: add al,dh > 0x60: add ax,0xcf > 0x63: lock repnz out 0x0,al This code makes no sense, it looks like the processor has gone into the weeds. :( Based on this: cs 0x9020 36896 I could guess, based on your use of resource2_wc, that the host is bypassing the processor cache but the guest is not. This use is not supported on x86 KVM, sorry. Paolo ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Guest memory backed by PCI BAR (x86) 2015-03-26 16:40 ` Paolo Bonzini @ 2015-03-26 16:52 ` Nate Case 2015-03-26 17:04 ` Paolo Bonzini 0 siblings, 1 reply; 10+ messages in thread From: Nate Case @ 2015-03-26 16:52 UTC (permalink / raw) To: Paolo Bonzini; +Cc: kvm ----- Original Message ----- > > > On 26/03/2015 17:34, Nate Case wrote: > > 0x52: add al,dh > > 0x54: pop cx > > 0x55: clc > > 0x56: add al,dh > > => 0x58: cs > > 0x59: call 0xf05c > > 0x5c: shr bh,cl > > 0x5e: add al,dh > > 0x60: add ax,0xcf > > 0x63: lock repnz out 0x0,al > > This code makes no sense, it looks like the processor has gone into the > weeds. :( > > Based on this: > > cs 0x9020 36896 > > I could guess, based on your use of resource2_wc, that the host is > bypassing the processor cache but the guest is not. This use is not > supported on x86 KVM, sorry. I don't think the "x/70i 0" output reflected where the CPU was actually executing? Based on the CS:IP of 9020:0058 (0x90258), shouldn't I be dumping from around 0x90200 instead? gdb gets easily confused here real-mode-gdb$ x/70i 0x90200 0x90200: cli 0x90201: mov al,0x80 0x90203: out 0x70,al 0x90205: mov ax,0x9000 0x90208: mov ds,ax 0x9020a: mov es,ax 0x9020c: mov fs,ax 0x9020e: mov ss,ax 0x90210: mov sp,dx 0x90212: push cs 0x90213: pop ds 0x90214: lidtw ds:0xa2 0x90219: lgdtw ds:0xa8 0x9021e: mov dx,0x92 0x90221: in al,dx 0x90222: cmp al,0xff 0x90224: je 0x90238 0x90226: mov ah,BYTE PTR [esp+0x4] 0x9022b: test ah,ah 0x9022d: je 0x90233 0x9022f: or al,0x2 0x90231: jmp 0x90235 0x90233: and al,0xfd 0x90235: and al,0xfe 0x90237: out dx,al 0x90238: call 0x90266 0x9023b: mov al,0xd1 0x9023d: out 0x64,al 0x9023f: call 0x90266 0x90242: mov al,0xdf 0x90244: out 0x60,al 0x90246: call 0x90266 0x90249: mov ax,0x1 0x9024c: lmsw ax 0x9024f: jmp 0x90251 0x90251: mov ax,0x18 0x90254: mov ds,ax 0x90256: mov es,ax 0x90258: mov ss,ax <-- the "real" IP 0x9025a: mov fs,ax 0x9025c: mov gs,ax 0x9025e: jmp 0x10:0x10000 0x90266: call 0x9027f 0x90269: in al,0x64 0x9026b: cmp al,0xff 0x9026d: je 0x9027e 0x9026f: test al,0x1 0x90271: je 0x9027a 0x90273: call 0x9027f 0x90276: in al,0x60 0x90278: jmp 0x90266 0x9027a: test al,0x2 0x9027c: jne 0x90266 0x9027e: ret 0x9027f: jmp 0x90281 0x90281: ret 0x90282: add BYTE PTR [bx+si],al 0x90284: add BYTE PTR [bx+si],al 0x90286: add BYTE PTR [bx+si],al 0x90288: add BYTE PTR [bx+si],al 0x9028a: add BYTE PTR [bx+si],al 0x9028c: add BYTE PTR [bx+si],al 0x9028e: add BYTE PTR [bx+si],al 0x90290: add BYTE PTR [bx+si],al 0x90292: (bad) 0x90293: jg 0x90295 0x90295: add BYTE PTR [bx+si],al 0x90297: call 0xffff:0xc0 0x9029c: (bad) 0x9029d: (bad) Thanks, Nate ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Guest memory backed by PCI BAR (x86) 2015-03-26 16:52 ` Nate Case @ 2015-03-26 17:04 ` Paolo Bonzini 2015-03-26 17:14 ` Nate Case 2015-03-27 15:27 ` Nate Case 0 siblings, 2 replies; 10+ messages in thread From: Paolo Bonzini @ 2015-03-26 17:04 UTC (permalink / raw) To: Nate Case; +Cc: kvm On 26/03/2015 17:52, Nate Case wrote: > I don't think the "x/70i 0" output reflected where the CPU was actually > executing? Based on the CS:IP of 9020:0058 (0x90258), shouldn't I be > dumping from around 0x90200 instead? gdb gets easily confused here Ah, this was gdb (QEMU has its own monitor and it sums the CS base if you use $pc, but not if you write an absolute address). > 0x90249: mov ax,0x1 > 0x9024c: lmsw ax > 0x9024f: jmp 0x90251 > 0x90251: mov ax,0x18 > 0x90254: mov ds,ax > 0x90256: mov es,ax > 0x90258: mov ss,ax <-- the "real" IP > 0x9025a: mov fs,ax > 0x9025c: mov gs,ax > 0x9025e: jmp 0x10:0x10000 This makes more sense. The processor is looking at this code at least until 0x9024c, because of this in the trace: qemu-system-x86-3937 [002] 1474032.001887: kvm_exit: reason CR_ACCESS rip 0x4c qemu-system-x86-3937 [002] 1474032.001887: kvm_cr: cr_write 0 = 0x11 (bit 4 is always 1 so you see 0x11). However, the trace then shows a crash (triple fault) at 0x63, not 0x58. Please run "info registers" from QEMU instead, so that it's possible to see the hidden part of the segment registers. Paolo > 0x90266: call 0x9027f > 0x90269: in al,0x64 > 0x9026b: cmp al,0xff > 0x9026d: je 0x9027e > 0x9026f: test al,0x1 > 0x90271: je 0x9027a > 0x90273: call 0x9027f > 0x90276: in al,0x60 > 0x90278: jmp 0x90266 > 0x9027a: test al,0x2 > 0x9027c: jne 0x90266 > 0x9027e: ret > 0x9027f: jmp 0x90281 > 0x90281: ret > 0x90282: add BYTE PTR [bx+si],al > 0x90284: add BYTE PTR [bx+si],al > 0x90286: add BYTE PTR [bx+si],al > 0x90288: add BYTE PTR [bx+si],al > 0x9028a: add BYTE PTR [bx+si],al > 0x9028c: add BYTE PTR [bx+si],al > 0x9028e: add BYTE PTR [bx+si],al > 0x90290: add BYTE PTR [bx+si],al > 0x90292: (bad) > 0x90293: jg 0x90295 > 0x90295: add BYTE PTR [bx+si],al > 0x90297: call 0xffff:0xc0 > 0x9029c: (bad) > 0x9029d: (bad) > > Thanks, > > Nate > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Guest memory backed by PCI BAR (x86) 2015-03-26 17:04 ` Paolo Bonzini @ 2015-03-26 17:14 ` Nate Case 2015-03-27 15:27 ` Nate Case 1 sibling, 0 replies; 10+ messages in thread From: Nate Case @ 2015-03-26 17:14 UTC (permalink / raw) To: Paolo Bonzini; +Cc: kvm > Ah, this was gdb (QEMU has its own monitor and it sums the CS base if > you use $pc, but not if you write an absolute address). Thanks, that's useful to know! I didn't realize QEMU supported this. > However, the trace then shows a crash (triple fault) at 0x63, not 0x58. > > Please run "info registers" from QEMU instead, so that it's possible to > see the hidden part of the segment registers. Here is the register dump from QEMU: (qemu) info registers EAX=00000018 EBX=00000000 ECX=00002000 EDX=00000092 ESI=00005a00 EDI=00003ff4 EBP=000001d0 ESP=00000800 EIP=00000058 EFL=00010046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0018 ffffffff ffffffff 00f0ff00 DPL=3 CS64 [CRA] CS =9020 00090200 ffffffff 00809b00 DPL=0 CS16 [-RA] SS =9000 00090000 ffffffff 00809300 DPL=0 DS16 [-WA] DS =0018 ffffffff ffffffff 00f0ff00 DPL=3 CS64 [CRA] FS =9000 00090000 ffffffff 00809300 DPL=0 DS16 [-WA] GS =9000 00090000 ffffffff 00809300 DPL=0 DS16 [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy GDT= 00090282 00000800 IDT= 00000000 00000000 CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 Thanks, Nate ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Guest memory backed by PCI BAR (x86) 2015-03-26 17:04 ` Paolo Bonzini 2015-03-26 17:14 ` Nate Case @ 2015-03-27 15:27 ` Nate Case 1 sibling, 0 replies; 10+ messages in thread From: Nate Case @ 2015-03-27 15:27 UTC (permalink / raw) To: Paolo Bonzini; +Cc: kvm > > 0x90249: mov ax,0x1 > > 0x9024c: lmsw ax > > 0x9024f: jmp 0x90251 > > 0x90251: mov ax,0x18 > > 0x90254: mov ds,ax > > 0x90256: mov es,ax > > 0x90258: mov ss,ax <-- the "real" IP > > 0x9025a: mov fs,ax > > 0x9025c: mov gs,ax > > 0x9025e: jmp 0x10:0x10000 > > This makes more sense. The processor is looking at this code at least > until 0x9024c, because of this in the trace: > > qemu-system-x86-3937 [002] 1474032.001887: kvm_exit: reason > CR_ACCESS rip 0x4c > qemu-system-x86-3937 [002] 1474032.001887: kvm_cr: cr_write 0 > = 0x11 > > (bit 4 is always 1 so you see 0x11). > > However, the trace then shows a crash (triple fault) at 0x63, not 0x58. I was curious about the crash at 0x63 instead of 0x58, and I realized that the first trace I uploaded had some debug code in the memtest86 setup.S which would have moved the instruction addresses around. So the trace addresses wouldn't have matched the assembly dump exactly. I uploaded a cleaner trace here: http://oss.xes-inc.com/xtmp/trace-pcimem-memtest86-stock-reset.dat.gz This was used with the stock memtest86 code and also with "-no-reboot" so you don't see the subsequent boot in the trace. In this trace, at the end the last guest_rip reference I see is 0x58 now: kvm_exit: [FAILED TO PARSE] exit_reason=30 guest_rip=0x69 kvm_pio: pio_read at 0x64 size 1 count 1 kvm_entry: vcpu 0 kvm_exit: [FAILED TO PARSE] exit_reason=28 guest_rip=0x4c kvm_cr: cr_write 0 = 0x11 kvm_mmu_get_page: [FAILED TO PARSE] gfn=0 role=983104 root_count=0 unsync=0 created=0 kvm_entry: vcpu 0 kvm_exit: [FAILED TO PARSE] exit_reason=2 guest_rip=0x58 QEMU register dump after the failure looks the same as my last post: (qemu) info registers EAX=00000018 EBX=00000000 ECX=00002000 EDX=00000092 ESI=00005a00 EDI=00003ff4 EBP=000001d0 ESP=00000800 EIP=00000058 EFL=00010046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0018 ffffffff ffffffff 00f0ff00 DPL=3 CS64 [CRA] CS =9020 00090200 ffffffff 00809b00 DPL=0 CS16 [-RA] SS =9000 00090000 ffffffff 00809300 DPL=0 DS16 [-WA] DS =0018 ffffffff ffffffff 00f0ff00 DPL=3 CS64 [CRA] FS =9000 00090000 ffffffff 00809300 DPL=0 DS16 [-WA] GS =9000 00090000 ffffffff 00809300 DPL=0 DS16 [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy GDT= 00090282 00000800 IDT= 00000000 00000000 CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 Instruction dump (matches setup.S code from memtest86+): (qemu) x/60i 0x90200 0x0000000000090200: cli 0x0000000000090201: mov $0x80,%al 0x0000000000090203: out %al,$0x70 0x0000000000090205: mov $0x9000,%ax 0x0000000000090208: mov %ax,%ds 0x000000000009020a: mov %ax,%es 0x000000000009020c: mov %ax,%fs 0x000000000009020e: mov %ax,%ss 0x0000000000090210: mov %dx,%sp 0x0000000000090212: push %cs 0x0000000000090213: pop %ds 0x0000000000090214: lidtw 0xa2 0x0000000000090219: lgdtw 0xa8 0x000000000009021e: mov $0x92,%dx 0x0000000000090221: in (%dx),%al 0x0000000000090222: cmp $0xff,%al 0x0000000000090224: je 0x90238 0x0000000000090226: addr32 mov 0x4(%esp),%ah 0x000000000009022b: test %ah,%ah 0x000000000009022d: je 0x90233 0x000000000009022f: or $0x2,%al 0x0000000000090231: jmp 0x90235 0x0000000000090233: and $0xfd,%al 0x0000000000090235: and $0xfe,%al 0x0000000000090237: out %al,(%dx) 0x0000000000090238: call 0x90266 0x000000000009023b: mov $0xd1,%al 0x000000000009023d: out %al,$0x64 0x000000000009023f: call 0x90266 0x0000000000090242: mov $0xdf,%al 0x0000000000090244: out %al,$0x60 0x0000000000090246: call 0x90266 0x0000000000090249: mov $0x1,%ax 0x000000000009024c: lmsw %ax 0x000000000009024f: jmp 0x90251 0x0000000000090251: mov $0x18,%ax 0x0000000000090254: mov %ax,%ds 0x0000000000090256: mov %ax,%es 0x0000000000090258: mov %ax,%ss <- pc 0x000000000009025a: mov %ax,%fs 0x000000000009025c: mov %ax,%gs 0x000000000009025e: ljmpl $0x10,$0x10000 0x0000000000090266: call 0x9027f 0x0000000000090269: in $0x64,%al 0x000000000009026b: cmp $0xff,%al 0x000000000009026d: je 0x9027e 0x000000000009026f: test $0x1,%al 0x0000000000090271: je 0x9027a 0x0000000000090273: call 0x9027f 0x0000000000090276: in $0x60,%al 0x0000000000090278: jmp 0x90266 0x000000000009027a: test $0x2,%al 0x000000000009027c: jne 0x90266 0x000000000009027e: ret 0x000000000009027f: jmp 0x90281 0x0000000000090281: ret 0x0000000000090282: add %al,(%bx,%si) 0x0000000000090284: add %al,(%bx,%si) 0x0000000000090286: add %al,(%bx,%si) 0x0000000000090288: add %al,(%bx,%si) I also switched to using sysfs file "resource2" for now instead of "resource2_wc", but the behavior appears to be the same in both cases. Thanks, Nate ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-03-27 15:27 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-03-25 15:56 Guest memory backed by PCI BAR (x86) Nate Case 2015-03-26 14:02 ` Paolo Bonzini 2015-03-26 16:01 ` Nate Case 2015-03-26 16:07 ` Paolo Bonzini 2015-03-26 16:34 ` Nate Case 2015-03-26 16:40 ` Paolo Bonzini 2015-03-26 16:52 ` Nate Case 2015-03-26 17:04 ` Paolo Bonzini 2015-03-26 17:14 ` Nate Case 2015-03-27 15:27 ` Nate Case
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox