On 19/08/14 12:31, Paolo Bonzini wrote: > Il 19/08/2014 12:09, Christian Borntraeger ha scritto: >>> I'm not sure, this does seem like a workaround for another >>> limitation after all... Gleb? >> >> Yes. We want to get rid of KVM_S390_INITIAL_RESET in QEMU. This comes >> from a time, when we had another userspace prototype for KVM on s390 >> (kuli). Its really a wart that has to go. Its just that we are not >> there yet to remove the call to KVM_S390_INITIAL_RESET. Doing so can >> result in hard to debug errors after reboot, if an interrupt was made >> pending just before reboot that gets delivered in the new instance. >> >> The new way for local interrupt read/write will probably be some >> onereg or syncreg interface with a bitmask register and payload >> registers. We have to solve some concurrency and implemenation issues >> here. > > Yes, I understand; the plan is fine and it's good that it was already on > your todo list. > > But since you acknowledge that KVM_S390_INITIAL_RESET will go, I'm not > sure we want to apply this patch (except for the pid == 0 part, of > course---that one is good). Well, it makes todays QEMU (a lot) faster on s390 bootup with many CPUs. (According to strace on my system the first GET_FPU ioctl takes up to 0.079 sec. With 64 CPUs this sums up to several seconds. But I understand your concern of touching generic KVM code only if really necessary. Let me know if I should send a minimal pid==0 version. (I would prefer the full version, of course). Christian -- 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
