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. However, that being said I really saw my implementation as "cheating". In a clean design, the apic-bus model should be independent of the kvm to vcpu mapping. The apic-bus should never really "see" the entire VM. It should only see itself as a bus with some interconnected APICs to talk to. If that were true, your decision to move the kvm->vcpu array to a list would be inconsequential to the in-kernel APIC code. This extra level of modeling never came to be in my now defunct series, however. So in summary, I don't think moving to a list like you did is a terrible thing, but other provisions will have to be made if you are not providing a good mapping mechanism. E.g. either a proper apic-bus model will have to map processor-id to apic independently, or your kvm->vcpu mapping will need to be adaptable to relatively efficient lookups (hlist, maybe?). > 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. > > > > + 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. As Avi said, only the APIC (or more specifically, the apic-bus model) should care. But this is _very_ important. Interrupt messages have destination addresses expressed in terms of these IDs ;) Regards, -Greg ------------------------------------------------------------------------- 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
