On Thu, 2007-07-26 at 19:50 -0400, Gregory Haskins wrote: > On Fri, 2007-07-27 at 09:27 +1000, Rusty Russell wrote: > > > So the in-kernel apic code has to traverse every element in the array? > > That is clearly better because? > > I can't speak for Eddie's implementation, but the one that I had worked > on did in fact take advantage of the array. Not for traversing it as > you suggested, but rather for efficient mapping of vcpu ID to APIC. The > modeled "APIC BUS" already knew its targets. It would then use > "kvm->vcpus[target]" to find the right APIC.
That makes sense. Looks like Eddie's ioapic code uses a similar trick in ioapic_deliver's dest_Fixed case. I'll revert to an array, but I'll drop the nvcpus var: scanning for NULLs is so fast it won't be measurable. > > We get to place an artificial maximum > > and keep a ceiling variable like the existing code does? > > This always bothered me too. But I guess realistically some reasonable > ceiling could probably be found (something in the 8-64 range sounds > right to me) if the dynamic list idea is shot down. If we do go this > static route, it should probably be in the Kconfig. I agree: Qemu supports up to 255 processors, but that's kind of silly if it's static. I'll leave the current limit (4) and let someone else code up a dynamic one. Thanks! Rusty. ------------------------------------------------------------------------- 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
