On Mon, Oct 12, 2009 at 11:30:10AM +0200, Avi Kivity wrote: > On 10/12/2009 11:25 AM, Jan Kiszka wrote: > >>>Or what is the > >>>alternative? > >>> > >>irqfd (which only supports edge-triggered interrupts now). Note irqfd > >>needs the same love, it uses a workqueue as well. > >> > >>The theory is: > >> fd1 = eventfd() > >> give fd1 to kvm as irqfd, vhost-net as trigger fd > >> fd2 = eventfd() > >> give fd2 to kvm as irqfd, uio as trigger fd > >> fd3 = evenfd() > >> give fd3 to kvm as irqfd, another kvm as ioeventfd > >> > >>One interface, multiple users (in the kernel, userspace, or other > >>processes) > >I see to overall gain, but likely only worsens my objective (low > >latency), at least it doesn't improve it. > > irqfd can work from interrupt context, so if we only use the > workqueue for the many-vcpu cases, we should be fine. > > I think we can do it cleanly, too: in ioapic code, if we're talking > to one vcpu, wake it immediately; otherwise schedule work to > continue in process context. This was the common code can always > work in interrupt context and not worry about the work queue. > Even if we are talking to one cpu locking is still needed, so unless we make it spinlock we can't inject from irq context. If we change mutex to spinlock what is the point of work queue? -- 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
