On 2012-10-23 12:52, Peter Maydell wrote: > On 23 October 2012 11:48, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: >> The current irqchip API is like this: >> >> KVM_CREATE_IRQCHIP (without any parameters) >> ... >> KVM_CREATE_VCPU >> KVM_SET_IRQCHIP (or the other way around) >> ... >> KVM_RUN >> >> The arguments you cannot pass via KVM_CREATE_IRQCHIP - which is more >> like a "Hey, there will be an IRQ chip!" - could be passed via >> KVM_SET_IRQCHIP (it has 512 bytes space). Provided there are sane >> configuration defaults, at least after KVM_CREATE_VCPU, KVM_SET_IRQCHIP >> becomes optional. Then you don't need the a check on KVM_RUN. > > KVM_SET_IRQCHIP is the state load ioctl, right (companion to > KVM_GET_IRQCHIP)? It seems like a bit of an abuse to use that > for configuration rather than for migration/sync of state > with userspace... Depends on how reconfigurable your chip is. x86 also sends the mapping down this way, which happens to be guest configurable but is practically static. > > (For ARM we will just use the ONE_REG ABI for irqchip state > save/load anyway, so KVM_SET_IRQCHIP isn't relevant.) The less problems you should have using the SET interface to perform one-time configuration. BTW, I guess we will regret that one-reg ABI one day and have to introduce a multi-reg version again for hot-standby, i.e. continuous state migration. I know we also do this for c86 MSRs - that interface has the same limitation. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- 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
