2015-08-06 15:52+0200, Paolo Bonzini: > On 06/08/2015 15:44, Radim Krčmář wrote: >> The two obvious extensions are flags to skip kvm_make_request() or >> kvm_vcpu_kick(), both of dubious use. > > Skipping kvm_make_request() would make some sense if you can set > vcpu->run->request_interrupt_window asynchronously. So you could do > > vcpu->run->request_interrupt_window = 1; > ioctl(vcpu_fd, KVM_USER_EXIT, KVM_USER_EXIT_LAZY); > > and only cause a lightweight vmexit if the interrupt window is currently > closed. I haven't thought of any races that could happen, but it looks > like it could work. Seems doable, kvm_run should have been better protected :) > Skipping kvm_vcpu_kick() makes much less sense. Could save some cycles when queuing an early exit from the VCPU thread. >> Another possibility is setting up >> conditional exits, but that would be better as a separate control, like >> most other sophisticated extensions. >> >> I think that u32 flags would be sufficient -- is casting the 'unsigned >> long arg' (data pointer) to a value still an accepted solution? > > Yeah, that would work for me as well. Also because, for now, you'd > return EINVAL if the unsigned long is not zero, which boils down to > "return EINVAL if the parameter is not NULL". :) Exactly, only the ioctl number will change. -- 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
