From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLw9W-00013Z-DP for qemu-devel@nongnu.org; Wed, 20 Jan 2016 12:02:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLw9Q-00078I-N1 for qemu-devel@nongnu.org; Wed, 20 Jan 2016 12:02:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53117) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLw9Q-000787-Ha for qemu-devel@nongnu.org; Wed, 20 Jan 2016 12:02:32 -0500 References: <1452595842-20880-1-git-send-email-asmetanin@virtuozzo.com> <1452595842-20880-5-git-send-email-asmetanin@virtuozzo.com> <009401d14ea5$dc8cf250$95a6d6f0$@samsung.com> <569F92AC.4030506@redhat.com> <20160120152034.GA3947@rkaganb.sw.ru> From: Paolo Bonzini Message-ID: <569FBDA1.7010704@redhat.com> Date: Wed, 20 Jan 2016 18:02:25 +0100 MIME-Version: 1.0 In-Reply-To: <20160120152034.GA3947@rkaganb.sw.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v1 4/5] kvm/x86: Hyper-V VMBus hypercall userspace exit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Roman Kagan' , Pavel Fedin , 'Andrey Smetanin' , kvm@vger.kernel.org, 'Gleb Natapov' , 'Joerg Roedel' , "'K. Y. Srinivasan'" , 'Haiyang Zhang' , "'Denis V. Lunev'" , qemu-devel@nongnu.org On 20/01/2016 16:20, 'Roman Kagan' wrote: >> > Because, as the docs say, we don't want to do that. We want to use >> > KVM_EXIT_IO or KVM_EXIT_MMIO, with two exceptions: s390 and wherever we >> > can't do that for compatibility purposes. > I must admit I saw this part in the docs but failed to understand it. > > Is it supposed to mean that we want to avoid using hypercalls as a means > of guest communications with the host userspace in general, and use PIO > or MMIO instead, unless hypercalls are mandated by a guest implemenation > we can't affect (as is the case for Hyper-V)? In this case we use hypercalls. :) However, we use a separate exit instead of putting everything under KVM_EXIT_HYPERCALL. This, as you mentioned, has the advantage that you can customize it according to the calling convention (which may help avoiding TOCTTOU issues, too). > Because *implementing* Hyper-V hypercalls in terms of KVM_EXIT_IO or > KVM_EXIT_MMIO looked hard at best. > >> > So we should not add a new exit > Why? VCPU exit codes are not a scarse resource. Indeed, but grouping makes things easier to understand. > So far we've envisaged two reasons for VCPU exit related to hyper-v: one > for hyper-v MSRs and the other for hypercalls. Since there was a > discussion on implementing generic MSR access by Peter we thought it > wiser to introduce a new VCPU exit for hyper-v hypercalls to avoid > interfering with the MSR implementation. That's a good idea. However, I think I'm not going to accept the MSR exit feature, and then the current Hyper-V exit API makes some sense indeed (it's just 3 values, transferring them all at once is not expensive at all). Paolo