On 09/17/2010 09:12 PM, Marcelo Tosatti wrote:
> This is now merged, with the change pointed out by Marcelo. Windows > XP x64 fails installation without > > (vmx.c handle_cr()) > case 8: { > u8 cr8_prev = kvm_get_cr8(vcpu); > u8 cr8 = kvm_register_read(vcpu, reg); > kvm_set_cr8(vcpu, cr8); > skip_emulated_instruction(vcpu); > if (irqchip_in_kernel(vcpu->kvm)) > return 1; > - if (cr8_prev<= cr8) > - return 1; > vcpu->run->exit_reason = KVM_EXIT_SET_TPR; > return 0; > } > > Which doesn't make any sense (anyone?). The failure is present even > without the patchset, and is fixed by the same hack, so a regression > was not introduced. If userspace does not have an uptodate TPR value, it can signal an interrupt that is now blocked? Say: - cr8 write 0 - cr8 write 5 - no exit to userspace - userspace signals interrupt with priority 4 because it knows about tpr == 0.
To signal an interrupt, userspace needs to force an exit. The exit will sync cr8.
However, it may be that the decision to inject the interrupt is taken before the exit, so the interrupt is injected even though it shouldn't be.
Let's assume that this is so (I'll check). Is this a bug in the kernel or userspace?
My feeling is that this is a kernel bug, and the optimization should be removed.
-- 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