Re: [RFC 7/11] virtio_pci: new, capability-aware driver.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux