On 2012-07-26 12:49, Jan Kiszka wrote: > On 2012-07-26 12:45, Avi Kivity wrote: >> On 07/26/2012 01:29 PM, Jan Kiszka wrote: >> >>>> It looks like general memory corruption. Is this repeatable? What's >>>> the guest uptime when it happens (i.e. is it immediate?) >>>> >>>> Jan, why are we calling cpu_set_apic_tpr() with kvm_irqchip_in_kernel? >>> >>> To sync the userspace state with what the kernel maintains. Will end up >>> in kvm_apic_set_tpr which does precisely this. We always did, just the >>> QOM modeling is new. >> >> We should move it to the general register synchronization code, there is >> no reason to do this every exit (though the cost is likely minimal). > > The cost is, well, was close to nothing. But I'm not sure about that QOM > type casting magic (and also it's locking requirements, long-term). > However, if that is a problem, it's likely a much bigger one anyway. But, independent of this, we can likely move the whole kvm_arch_post_run out of the exit path for kvm_irqchip_in_kernel() == true. The price is that we create more deviation between both, but that should be controllable. I will play with a patch. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- 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
