On Fri, 2007-08-24 at 22:24 +0800, Dong, Eddie wrote: > [EMAIL PROTECTED] wrote: > > Gregory Haskins wrote: > >> On Fri, 2007-08-24 at 21:08 +0800, Dong, Eddie wrote: > >>> Avi: > >>> > >>> apic->lock is used in many place to avoid race condition with > >>> apic timer call back function which may run on different pCPU. > >>> This patch migrate the apic timer to same CPU with the one VP > >>> runs on, thus the lock is no longer necessary. > >>> > >> > >> What about sources that can inject interrupts besides the timer? > >> (E.g. in-kernel PV drivers) > > > > Injecting IRQ is OK, since it is just operation to IRR > > register which we > > can > > use atomic operations. Xen also do in that way. > > > O, said too quick. Xen current has evolved to be protected by a > bigger irqlock for both APIC & IOAPIC, and PIC uses per chip lock. > > For our case, PIC/IOAPIC now is using kvm->lock. So APIC is working > with kvm->lock too. But this lock may be too big for pv driver. We may > need to think of a solution to cover both APIC & IOAPIC in future.
Yeah, I would highly recommend you make this more fine grained. For example, I had a vcpu->irq.lock, and a per-chip lock (e.g. one per apic, per pic, (and one per ioapic but I never got there)). Event injection is a hot-spot, so coarse locking is probably going to cause performance deficiencies. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
