On 04/28/2012 12:49 AM, Marcelo Tosatti wrote: > > >> + smp_mb(); > > >> + vcpu->mode = OUTSIDE_GUEST_MODE; > > > > > > Don't you want > > > > > > vcpu->mode = OUTSIDE_GUEST_MODE; > > > smp_mb(); > > > > > > > > > It is unsafe i think, it is a problem if spte read / spte update is ordered > > to the behind of vcpu->mode = OUTSIDE_GUEST_MODE, like below: > > > > VCPU 0 VCPU 1 > > commit_zapped_page: > > /* > > * setting vcpu->mode is reordered > > * to the head of read spte. > > */ > > vcpu->mode = OUTSIDE_GUEST_MODE; > > > > see VCPU 0 is out-of-guest-mode, IPI is > > not sent, and the sp is free immediately. > > > > read spte; > > OOPS!!! Ouch! > > > > (It is invalid since spte is freed.) > > > > smp_mb > > Right. In that case a compiler barrier is sufficient (stores are not > reordered with earlier loads on x86). I think it's customary not to depend on arch specific memory barrier behaviour (but I don't have anything to base this on, just a feeling). -- 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
