On 10/20/2012 12:39 AM, Stefan Fritsch wrote: > On Thursday 18 October 2012, Avi Kivity wrote: >> On 10/18/2012 11:35 AM, Gleb Natapov wrote: >> > You misunderstood the description. V_INTR_MASKING=1 means that >> > CR8 writes are not propagated to real HW APIC. >> > >> > But KVM does not trap access to CR8 unconditionally. It enables >> > CR8 intercept only when there is pending interrupt in IRR that >> > cannot be immediately delivered due to current TPR value. This >> > should eliminate 99% of CR8 intercepts. >> >> Right. You will need to expose the alternate encoding of cr8 (IIRC >> lock mov reg, cr0) on AMD via cpuid, but otherwise it should just >> work. Be aware that this will break cross-vendor migration. > > I get an exception and I am not sure why: > > kvm_entry: vcpu 0 > kvm_exit: reason write_cr8 rip 0xd0203788 info 0 0 > kvm_emulate_insn: 0:d0203788: f0 0f 22 c0 (prot32) > kvm_inj_exception: #UD (0x0) > > This is qemu-kvm 1.1.2 on Linux 3.2. > > When I look at arch/x86/kvm/emulate.c (both the current and the v3.2 > version), I don't see any special case handling for "lock mov reg, > cr0" to mean "mov reg, cr8".
emulate.c will #UD is the Lock flag is missing in the instruction decode table. > Before I spend lots of time on debugging my code, can you verify if > the alternate encoding of cr8 is actually supported in kvm or if it is > maybe missing? Thanks in advance. With the decode table fix I think it should work. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
