On Thu, May 21, 2009 at 11:06:42PM +0300, Gleb Natapov wrote: > > Why don't make a convention that vcpu_id 0 is the BSP, by default, > > instead of the first vcpu created? This way if userspace creates vcpu 3 > > first, there are no problems. > > > Because userspace no longer control vcpu_id allocation. I also want to > get rid of "first vcpu is bsp" restriction, but this fill require new > ioctl I guess. Or hardcode "apic_id == 0 is BSP" for now, and later add an ioctl to set the BSP? > > That brings the question, why is the apic_id passed as the argument to > > vcpu_create? It seems that the argument to vcpu_create should be the > > kVM's internal vcpu_id, and the apic_id should come from somewhere else, > > apic_mmio_write maybe? > I think exactly opposite :) Why userspace should care what index vcpu > occupies in internal kernel data structure? This information is never > ever used by userspace again. At the moment its used to implicitly set the BSP (BSP is vcpu_id == 0). > And there is no reason to have vcpus array at all. It can be linked > list. > > Apic_id on the other hand comes from HW (sampled from pins A11# and A12# > and pins BR0# through BR3# see Intel SDM 9.4.6) and has to be configured > at vcpu creation time before vcpu is made accessible (been put into vcpus > array) to other parts of the code (such as ioapic). And mmio_writes is not > the way to configure apic_id either. It is hard to send INIT/SIPI to a AP > cpu before its apic_id is configured and only cpu itself can do mmio_write > into its apic :) And this is what Intel SDM has to say about it: > > Some processors permit software to modify the APIC ID. However, > the ability of software to modify the APIC ID is processor model > specific. Because of this, operating system software should avoid > writing to the local APIC ID register. > > > And indeed x2apic defines apic_id as non-writable. Thanks for correcting my ignorance :) > > > > AFAICS there is no linkage between apic_id and BSP (MP SPEC says BSP > There is no linkage between apic_id and BSP. Way do you think I suggest > different? Nevermind. > > is determined by hardware and BIOS), but in KVM's BIOS case the BSP is > > conventioned to be vcpu with vcpu_id == 0, no? > Yes (except not vcpu_id == 0, but apic_id == 0), we will have to fix this > bug too. Bios should get acpi_ids of active cpus from qemu, not assume > anything. > > > Another thing, it would be better if the linking of the vcpu in the > > array could be in arch independent code as it is today? > Possible, I will have to define kvm_arch_vcpu_find(id) function to > search for duplicates in generic code, but it will not be prettier. > I did it this way initially, but decided to hide everything in arch > code. Building on what you said, how KVM stores vcpu structures is no business of arch vcpu initialization code (or that should be the goal), IMO. -- 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
