Avi Kivity wrote: > On 09/01/2009 02:43 PM, Jan Kiszka wrote: >> @@ -3731,7 +3732,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu) >>> | (1<< VCPU_EXREG_PDPTR)); >>> vcpu->arch.regs_dirty = 0; >>> >>> - get_debugreg(vcpu->arch.dr6, 6); >>> + if (vcpu->arch.switch_db_regs) >>> + get_debugreg(vcpu->arch.dr6, 6); >>> >>> vmx->idt_vectoring_info = vmcs_read32(IDT_VECTORING_INFO_FIELD); >>> if (vmx->rmode.irq.pending) >>> >> That reduces the emulation quality as vcpu->arch.switch_db_regs is only >> set if some breakpoint is active while dr6 has its use also when that is >> not the case). >> > > True - there's the TF reason reporting bits. > > How about this then: > > - if !switch_db_regs, trap #DB > - on #DB trap, copy DR6.BS and DR6.BT to vcpu->arch.dr6, and reinject > the #DB > > ?
I'm worried about vm-exits that may take precedence over the #db trap. If we skip to save/restore dr6 for them, the value that the interception handler sees later on will be bogus. Or is this architecturally impossible? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- 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
