On 06.03.2013, at 12:46, Paolo Bonzini wrote: >> Please go ahead and try to describe an interface the way you envision >> it. It needs to fulfill the following criteria: >> >> * different machine models have different interrupt controller >> types >> * we need to be able to fetch information from interrupt >> controllers, this should be as flexible as possible because we >> don't know all future state we want to synchronize today >> * user space creates its virtual representation of an interrupt >> controller after the vcpus got created >> * user space needs a token to an interrupt controller, so that we >> have the possibility to add a second in-kernel irqchip if the need >> arises >> >> What the current interface does is: >> >> SET_IRQCHIP_TYPE: >> >> * declare CPUs as listeners to a specific irqchip bus >> * set the path that interrupt injection takes (this could >> probably be changed to dynamic lookups though, based on device >> tokens) >> >> CREATE_DEVICE: >> >> * spawn one or multiple in-kernel irqchip devices that hook up to >> CPUs using the irqchip bus >> * tell user space a token to access this irqchip >> >> I really don't see why you wouldn't want to have that split. > > I agree. But is the device really being created at CREATE_DEVICE time? > What happens if you create N CPUs and N-1 irqchips? irqchip in CREATE_DEVICE is the IOAPIC, not the LAPIC. The LAPIC gets spawned at vcpu creation. > On x86, the LAPIC is created magically together with the VCPU. Yes, and so far I haven't seen any proposal to change this even in the CREATE_DEVICE world. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
