On Thu, Nov 18, 2010 at 5:41 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Thu, Nov 18, 2010 at 11:30:47AM +0200, Avi Kivity wrote: >> >> >> >> *entry may be stale after rcu_read_unlock(). Is this a problem? >> > >> >I suppose not. All MSI-X MMIO accessing would be executed without delay, so >> >no re- >> >order issue would happen. If the guest is reading and writing the field at >> >the same >> >time(from two cpus), it should got some kinds of sync method for itself - >> >or it >> >may not care what's the reading result(like the one after msix_mask_irq()). >> >> I guess so. Michael/Alex? > > This is kvm_get_irq_routing_entry which is used for table reads, > correct? Actually, the pci read *is* the sync method that guests use, > they rely on reads to flush out all previous writes.
Michael, I think the *sync* you are talking about is not the one I meant. I was talking about two cpus case, one is reading and the other is writing, the order can't be determined if guest doesn't use lock or some other synchronize methods; and you're talking about to flush out all previous writes of the only one CPU... -- regards, Yang, Sheng -- 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
