hi,Kevin:
I applied the patch in 2.6.39-rc7+, and run a winxp vm, there is
many ICR write emulations, trace-cmd is as the following:
600281: kvm_entry: vcpu 0
600284: kvm_exit: reason APIC_ACCESS rip 0x806e7b85 info 3
600285: kvm_emulate_insn: 0:806e7b85: f7 05 00 03 fe ff 00 10 00 0
600286: kvm_apic: apic_read APIC_ICR = 0x40041
600286: kvm_mmio: mmio read len 4 gpa 0xfee00300 val 0x40041
600287: kvm_mmio: mmio write len 4 gpa 0xfee00300 val 0x40041
600287: kvm_apic: apic_write APIC_ICR = 0x40041
600287: kvm_apic_ipi: dst 1 vec 65 (Fixed|physical|de-assert|edge|self)
600288: kvm_apic_accept_irq: apicid 0 vec 65 (Fixed|edge)
600288: kvm_entry: vcpu 0
600289: kvm_exit: reason APIC_ACCESS rip 0x806e7b91 info 1
600290: kvm_emulate_insn: 0:806e7b91: 89 0d 00 03 fe ff
600291: kvm_mmio: mmio write len 4 gpa 0xfee00300 val 0x40041
600291: kvm_apic: apic_write APIC_ICR = 0x40041
600291: kvm_apic_ipi: dst 1 vec 65 (Fixed|physical|de-assert|edge|self)
600291: kvm_apic_accept_irq: apicid 0 vec 65 (Fixed|edge) (coalesced)
600292: kvm_entry: vcpu 0
600293: kvm_exit: reason APIC_ACCESS rip 0x806e7b97 info 3
600294: kvm_emulate_insn: 0:806e7b97: f7 05 00 03 fe ff 00 10 00 0
600294: kvm_apic: apic_read APIC_ICR = 0x40041
600295: kvm_mmio: mmio read len 4 gpa 0xfee00300 val 0x40041
600295: kvm_mmio: mmio write len 4 gpa 0xfee00300 val 0x40041
600295: kvm_apic: apic_write APIC_ICR = 0x40041
600296: kvm_apic_ipi: dst 1 vec 65 (Fixed|physical|de-assert|edge|self)
600296: kvm_apic_accept_irq: apicid 0 vec 65 (Fixed|edge) (coalesced)
as the asm code on addr 0x80637b85:
0x80637b85: testl $0x1000, 0xfffe0300
0x80637b8f: jne 0x80637b85
0x80637b91: mov %ecx, 0xfffe0300
0x80637b97: testl $0x1000, 0xfffe0300
0x80637ba1: jne 0x80637b97
I wonder why testl operation will also cause a ICR write, from the
asm code, there should only issue one IPI, but from trace-cmd, it
issued 3 IPI, is there something wrong?
Is it also possible to optimize ICR write emulation, from the
result, winxp vm will produce a lot of ICR writes
Regards!
Suya.
2011/8/29 Avi Kivity <avi@xxxxxxxxxx>:
> On 08/29/2011 04:55 PM, Jan Kiszka wrote:
>>
>> On 2011-08-29 13:11, Avi Kivity wrote:
>> > On 08/29/2011 02:03 PM, Jan Kiszka wrote:
>> >>>
>> >>> Just reading the first byte requires a guest page table walk. This
>> >>> is
>> >>> probably the highest cost in emulation (which also requires a walk
>> >>> for
>> >>> the data access).
>> >>
>> >> And what about caching the result of the first walk? Usually, a "sane
>> >> guest" won't have many code pages that issue the EIO.
>> >>
>> >
>> > There's no way to know when to invalidate the cache.
>>
>> Set the affected code page read-only?
>
> The virt-phys mapping could change too. And please, don't think of new
> reasons to write protect pages, they break up my lovely 2M maps.
>
>> >
>> > We could go a bit further, and cache the the whole thing. On the first
>> > exit, do the entire emulation, and remember %rip. On the second exit,
>> > if %rip matches, skip directly to kvm_lapic_eoi().
>> >
>> > But I don't think it's worth it. This also has failure modes, and
>> > really, no guest will ever write to EOI with stosl.
>>
>> ...or add/sub/and/or etc.
>
> Argh, yes, flags can be updated.
>
> Actually, this might work - if we get a read access first as part of the
> RMW, we'll emulate the instruction. No idea what the hardware does in this
> case.
>
>> Well, we've done other crazy things in the
>> past just to keep even the unlikely case correct. I was just wondering
>> if that policy changed.
>
> I can't answer yes to that question. But I see no way to make it work both
> fast and correct.
>
>>
>> However, I just realized that user space is able to avoid this
>> inaccuracy for potentially insane guests by not using in-kernel
>> irqchips. So we have at least a knob.
>
> Could/should have a flag to disable this in the kernel as well.
>
> --
> error compiling committee.c: too many arguments to function
>
> --
> 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
>
--
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
