On Thu, 2007-07-26 at 14:05 +0300, Avi Kivity wrote: > Rusty Russell wrote: > > Great minds think alike. This is a little rough, but I decided to send > > it out tonight because it would make your life easier... > > What about my life? Which patch should I apply first?
Such are the responsibilities of command, Avi. (Actually, the normal way is to send us both away to create a combined patch set, and thus make it Not Your Problem). > > === > > Dynamically allocate vcpus > > > > This patch converts the vcpus array in "struct kvm" to a linked list > > of VCPUs, and changes the "vcpu_create" and "vcpu_setup" hooks into > > one "vcpu_create" call which does the allocation and initialization of > > the vcpu (calling back into the kvm_vcpu_init core helper). > > Linked list? So that the in-kernel apic code has to traverse a list, > making sure the cpu still knows how to transfer dirty cache lines for > every vcpu? > > A good old fashioned pointer array will suit just fine. So the in-kernel apic code has to traverse every element in the array? That is clearly better because? We get to place an artificial maximum and keep a ceiling variable like the existing code does? > > + spin_lock(&kvm->lock); > > + /* What do we care if they create duplicate CPU ids? But be nice. */ > > > > Oh, we care. Esp. the apic code. Yeah, I left the check although it's currently unneeded, but I still don't think we should care. We shouldn't use the cpu_id internally, but use pointers. Sure, the guest might get confused, by that's not the kvm module's problem. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
