On Thu, Nov 18, 2010 at 8:33 PM, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > 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 <mst@xxxxxxxxxx> 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. ... I don't understand... We are emulating the writing operation using software and make it in effect immediately... What should we supposed to do with this "flush"? -- regards, Yang, Sheng -- 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
