Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754334AbbHGCiR (ORCPT ); Thu, 6 Aug 2015 22:38:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38254 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754088AbbHGCiP (ORCPT ); Thu, 6 Aug 2015 22:38:15 -0400 Date: Thu, 6 Aug 2015 19:21:08 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v2 4/5] KVM: add KVM_USER_EXIT vcpu ioctl for userspace exit Message-ID: <20150806172107.GB1481@potion.brq.redhat.com> References: <1438792381-19453-1-git-send-email-rkrcmar@redhat.com> <1438792381-19453-5-git-send-email-rkrcmar@redhat.com> <55C23B91.4010900@redhat.com> <20150806134415.GB31952@potion.brq.redhat.com> <55C36683.9050703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55C36683.9050703@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1577 Lines: 38 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/