Hi, Avi:
Your guess is right, the fast server is AMD with NPT. this slow
server is Intel's 7430 with no EPT, I now understand the reserved bit
come from kvm's virtual soft-mmu.
But there is still one confusing problem: why a FC14 VM has a much
better storage IO performance on the same host?
I always check the IO on host with iotop when copying files or
running fio in VM, when running with FC14 VM guest, it can reach
30Mbps; while copying file or running fio in winxp VM guest, it is
about 2-3Mbps.
FC14's trace-cmd output is as the following:
qemu-kvm-7636 [006] 897.452208: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.452213: kvm_exit:
reason EXCEPTION_NMI rip 0xffffffff8100b5fa
qemu-kvm-7636 [006] 897.452217: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.452408: kvm_exit:
reason EXTERNAL_INTERRUPT rip 0xffffffff81009ddd
qemu-kvm-7636 [006] 897.452411: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.452437: kvm_exit:
reason CR_ACCESS rip 0xffffffff8103fadd
qemu-kvm-7636 [006] 897.452437: kvm_cr:
cr_write 3 = 0x7a709000
qemu-kvm-7636 [006] 897.452442: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.453113: kvm_exit:
reason EXTERNAL_INTERRUPT rip 0xffffffff8103d12e
qemu-kvm-7636 [006] 897.453116: kvm_apic_accept_irq:
apicid 0 vec 239 (Fixed|edge)
qemu-kvm-7636 [006] 897.453120: kvm_inj_virq: irq 239
qemu-kvm-7636 [006] 897.453121: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.453126: kvm_exit:
reason APIC_ACCESS rip 0xffffffff81026239
qemu-kvm-7636 [006] 897.453134: kvm_mmio: mmio
write len 4 gpa 0xfee000b0 val 0x0
qemu-kvm-7636 [006] 897.453135: kvm_apic:
apic_write APIC_EOI = 0x0
qemu-kvm-7636 [006] 897.453137: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.453155: kvm_exit:
reason APIC_ACCESS rip 0xffffffff81026239
qemu-kvm-7636 [006] 897.453159: kvm_mmio: mmio
write len 4 gpa 0xfee00380 val 0xe6f5
qemu-kvm-7636 [006] 897.453160: kvm_apic:
apic_write APIC_TMICT = 0xe6f5
qemu-kvm-7636 [006] 897.453164: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.453373: kvm_exit:
reason IO_INSTRUCTION rip 0xffffffff812243e4
qemu-kvm-7636 [006] 897.453378: kvm_pio:
pio_write at 0xc050 size 2 count 1
qemu-kvm-7636 [006] 897.453625: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.453984: kvm_exit:
reason IO_INSTRUCTION rip 0xffffffff812243e4
qemu-kvm-7636 [006] 897.453984: kvm_pio:
pio_write at 0xc050 size 2 count 1
qemu-kvm-7636 [006] 897.454198: kvm_apic_accept_irq:
apicid 0 vec 239 (Fixed|edge)
qemu-kvm-7636 [006] 897.454201: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.454206: kvm_exit:
reason PENDING_INTERRUPT rip 0xffffffff81201c95
qemu-kvm-7636 [006] 897.454209: kvm_inj_virq: irq 239
qemu-kvm-7636 [006] 897.454209: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.454212: kvm_exit:
reason APIC_ACCESS rip 0xffffffff81026239
qemu-kvm-7636 [006] 897.454220: kvm_mmio: mmio
write len 4 gpa 0xfee000b0 val 0x0
qemu-kvm-7636 [006] 897.454222: kvm_apic:
apic_write APIC_EOI = 0x0
qemu-kvm-7636 [006] 897.454225: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.454238: kvm_exit:
reason APIC_ACCESS rip 0xffffffff81026239
qemu-kvm-7636 [006] 897.454243: kvm_mmio: mmio
write len 4 gpa 0xfee00380 val 0xd29f
qemu-kvm-7636 [006] 897.454243: kvm_apic:
apic_write APIC_TMICT = 0xd29f
qemu-kvm-7636 [006] 897.454247: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.454405: kvm_exit:
reason EXTERNAL_INTERRUPT rip 0xffffffff8113e91f
qemu-kvm-7636 [006] 897.454410: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.454547: kvm_exit:
reason IO_INSTRUCTION rip 0xffffffff812243e4
qemu-kvm-7636 [006] 897.454548: kvm_pio:
pio_write at 0xc050 size 2 count 1
qemu-kvm-7636 [006] 897.454690: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.454714: kvm_exit:
reason APIC_ACCESS rip 0xffffffff81026239
qemu-kvm-7636 [006] 897.454720: kvm_mmio: mmio
write len 4 gpa 0xfee00380 val 0x7ffffe
qemu-kvm-7636 [006] 897.454721: kvm_apic:
apic_write APIC_TMICT = 0x7ffffe
qemu-kvm-7636 [006] 897.454725: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.454730: kvm_exit:
reason APIC_ACCESS rip 0xffffffff81026239
qemu-kvm-7636 [006] 897.454733: kvm_mmio: mmio
write len 4 gpa 0xfee00380 val 0x1c040d
qemu-kvm-7636 [006] 897.454735: kvm_apic:
apic_write APIC_TMICT = 0x1c040d
qemu-kvm-7636 [006] 897.454737: kvm_entry: vcpu 0
qemu-kvm-7636 [006] 897.454745: kvm_exit:
reason HLT rip 0xffffffff8102b7f8
qemu-kvm-7525 [000] 897.458193: kvm_set_irq: gsi
26 level 1 source 0
qemu-kvm-7525 [000] 897.458195: kvm_msi_set_irq: dst 0
vec 51 (Fixed|physical|edge)
qemu-kvm-7525 [000] 897.458198: kvm_apic_accept_irq:
apicid 0 vec 81 (Fixed|edge)
qemu-kvm-7636 [006] 897.458238: kvm_inj_virq: irq 81
It seems that FC14 VM does not generate too much NMI interrupt.
I change virtio interface to IDE, IO performace can reach 19Mbps.
Regards.
Suya.
2011/8/11 Avi Kivity <avi@xxxxxxxxxx>:
> On 08/11/2011 08:41 AM, Tian, Kevin wrote:
>>
>> > qemu-system-x86-4454 [004] 549.958172: kvm_exit:
>> > reason EXCEPTION_NMI rip 0x8051d5e1
>> > qemu-system-x86-4454 [004] 549.958172: kvm_page_fault:
>> > address c8f8a000 error_code b
>>
>> error_code 'b' means the page fault is caused by a write access in kernel
>> space, but related page entry has reserved bit set. This is usually used
>> by
>> OS for some special tricks, e.g. to handle page swaps. You may check
>> related
>> setting in win guest.
>>
>
> In this case it was kvm setting the reserved bit.
>
> Looking at your other trace, that server is probably an AMD with the NPT
> feature, while your first one is an Intel without the equivalent (EPT). For
> this type of workload, you need EPT or NPT.
>
> --
> I have a truly marvellous patch that fixes the bug which this
> signature is too narrow to contain.
>
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
