On Thu, Nov 18, 2010 at 07:59:10PM +0800, Sheng Yang wrote: > On Thu, Nov 18, 2010 at 5:41 PM, Michael S. Tsirkin <[email protected]> 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...
Yes, but you don't seem to flush out writes on a read, either. > -- > regards, > Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
