On Wed, Oct 28, 2009 at 12:32:24PM +0200, Michael S. Tsirkin wrote: > On Wed, Oct 28, 2009 at 12:30:39PM +0200, Gleb Natapov wrote: > > On Wed, Oct 28, 2009 at 12:20:42PM +0200, Michael S. Tsirkin wrote: > > > On Wed, Oct 28, 2009 at 11:32:00AM +0200, Avi Kivity wrote: > > > > On 10/27/2009 07:50 PM, Michael S. Tsirkin wrote: > > > >> Can the value of irqchip_in_kernel be changed by userspace > > > >> after we have checked it? If yes, this check won't help ... > > > >> > > > > > > > > A change from false to true is possible, but not the reverse. > > > > > > Hmm. If we want to rely on this, we have to play with > > > memory barriers to write/read it. Doable, but hard to get right. > > Why? If userspace is so racy that it tries to use vpic while other > > thread creates it let it fail and burn in hell. > > Yes but reading uninitialized memory in kernel can > lead to host kernel crashes. > A you concerned that arch.vpic pointer assignment will be seen before vpic initialization? Yes this theoretically possible. > > > Can we always have the irqchip object exist? > > > It doesn't use a lot of memory, does it? > > > Maybe have it inline, save an extra indirection on > > > fastpath ... > > > > > > > -- > > > > error compiling committee.c: too many arguments to function > > > -- > > > 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 > > > > -- > > Gleb. -- Gleb. -- 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