On Fri, 13 Jan 2012 04:19:30 +0200, "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > On Thu, Jan 12, 2012 at 12:12:17PM +1030, Rusty Russell wrote: > > On Thu, 12 Jan 2012 00:02:33 +0200, "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > > > Look, we have a race currently. Let us not tie a bug fix to a huge > > > rewrite with unclear performance benefits, please. > > > > In theory, yes. In practice, we bandaid it. > > > > I think in the short term we change ->get to get the entire sequence > > twice, and check it's the same. Theoretically, still racy, but it does > > cut the window. And we haven't seen the bug yet, either. > > I thought about this some more. Since we always get > an interrupt on config changes, it seems that a rather > robust method would be to just synchronize against that. > Something like the below (warning - completely untested). > Still need to think about memory barriers, overflow etc. > What do you think? Ben's point about arbitrary delays in irq delivery still applies. If qemu changes config space the injects, there's a window there, too. But in practice, like my suggested double-read, it probably slows things down enough that it would be hard to hit. Testing required... Obviously, I'd like to fix this properly, but for legacy this might work fine. Cheers, Rusty. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
