On Thu, Jul 13, 2017 at 06:41:29PM +0200, Radim Krčmář wrote: > 2017-07-13 18:38+0200, Radim Krčmář: > > 2017-07-13 17:45+0200, Radim Krčmář: > > > 2017-07-13 18:29+0300, Roman Kagan: > > > > On Fri, Jun 23, 2017 at 12:54:25PM +0200, Paolo Bonzini wrote: > > > > > On 22/06/2017 15:51, Roman Kagan wrote: > > > > > Looks good, thanks. > > > > > > > > Are there still any problems with this series? > > > > I don't see it in kvm queue, so presumably it wasn't accepted... > > > > > > No, the problem was on my side. Queing it for the end of this merge > > > window. Thanks for the ping. > > > > And took it out after hitting a bug: we're asking for the VP_INDEX before the > > VCPU is in kvm->vcpus[], but the index is its position in that array. > > I think we can just use kvm->online_vcpus instead of kvm_vcpu_get_idx(). > > Ugh, definitely no, we're not under kvm->lock there. > Assigning the VP_INDEX in kvm_arch_vcpu_postcreate() would be doable, > but adding a new callback before exposing the VCPU fd is probably safer. But kvm_arch_vcpu_postcreate() *is* the last thing that's called before returning the VCPU fd. Isn't it the right place to do it? Or do you mean a dedicated kvm_hv_vcpu_postcreate() call rather than open-coding it there? Roman, fixing his scripts not to ignore errors from insmod when smoke-testing kernel modules (facepalm)...
