From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Fedin Subject: RE: [PATCH v1 4/5] kvm/x86: Hyper-V VMBus hypercall userspace exit Date: Thu, 14 Jan 2016 13:50:20 +0300 Message-ID: <00b201d14eb9$5d8ddeb0$18a99c10$@samsung.com> References: <1452595842-20880-1-git-send-email-asmetanin@virtuozzo.com> <1452595842-20880-5-git-send-email-asmetanin@virtuozzo.com> <009401d14ea5$dc8cf250$95a6d6f0$@samsung.com> <20160114102040.GA10363@rkaganb.sw.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: 'Andrey Smetanin' , kvm@vger.kernel.org, 'Gleb Natapov' , 'Paolo Bonzini' , 'Joerg Roedel' , "'K. Y. Srinivasan'" , 'Haiyang Zhang' , "'Denis V. Lunev'" , qemu-devel@nongnu.org To: 'Roman Kagan' Return-path: Received: from mailout1.w1.samsung.com ([210.118.77.11]:24777 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753953AbcANKuY (ORCPT ); Thu, 14 Jan 2016 05:50:24 -0500 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O0X00H45VFYQI40@mailout1.w1.samsung.com> for kvm@vger.kernel.org; Thu, 14 Jan 2016 10:50:22 +0000 (GMT) In-reply-to: <20160114102040.GA10363@rkaganb.sw.ru> Content-language: ru Sender: kvm-owner@vger.kernel.org List-ID: Hello! > We thought reusing KVM_EXIT_HYPERCALL was a bad idea exactly because of > that. Hypercalls are not universal, the calling and return conventions > are hypervisor-specific. Treatment of them is hypervisor-specific, but from CPUs point of view they are the same. You load something into registers, and execute hypercall instruction. So, you just need to pass registers in your structure. Or, you could even use generic register access APIs. > KVM already has to make the decision that the > particular vmexit is a HyperV hypercall; it appears unnatural to then > pass the data on to userspace in a generic structure and have them make > that decision again. Is it so difficult to make such a decision? The userland already knows what we are emulating. I'm afraid that in future we can end up in having 10 versions of KVM_EXIT_xxx_HYPERCALL with very small difference between them. Will it be good? Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJfU5-0005Ba-R6 for qemu-devel@nongnu.org; Thu, 14 Jan 2016 05:50:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJfU1-0006iZ-Px for qemu-devel@nongnu.org; Thu, 14 Jan 2016 05:50:29 -0500 Received: from mailout1.w1.samsung.com ([210.118.77.11]:24780) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJfU1-0006hj-Kf for qemu-devel@nongnu.org; Thu, 14 Jan 2016 05:50:25 -0500 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O0X00H45VFYQI40@mailout1.w1.samsung.com> for qemu-devel@nongnu.org; Thu, 14 Jan 2016 10:50:22 +0000 (GMT) From: Pavel Fedin References: <1452595842-20880-1-git-send-email-asmetanin@virtuozzo.com> <1452595842-20880-5-git-send-email-asmetanin@virtuozzo.com> <009401d14ea5$dc8cf250$95a6d6f0$@samsung.com> <20160114102040.GA10363@rkaganb.sw.ru> In-reply-to: <20160114102040.GA10363@rkaganb.sw.ru> Date: Thu, 14 Jan 2016 13:50:20 +0300 Message-id: <00b201d14eb9$5d8ddeb0$18a99c10$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-language: ru 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' Cc: kvm@vger.kernel.org, 'Gleb Natapov' , 'Joerg Roedel' , qemu-devel@nongnu.org, "'Denis V. Lunev'" , 'Andrey Smetanin' , 'Paolo Bonzini' , "'K. Y. Srinivasan'" , 'Haiyang Zhang' Hello! > We thought reusing KVM_EXIT_HYPERCALL was a bad idea exactly because of > that. Hypercalls are not universal, the calling and return conventions > are hypervisor-specific. Treatment of them is hypervisor-specific, but from CPUs point of view they are the same. You load something into registers, and execute hypercall instruction. So, you just need to pass registers in your structure. Or, you could even use generic register access APIs. > KVM already has to make the decision that the > particular vmexit is a HyperV hypercall; it appears unnatural to then > pass the data on to userspace in a generic structure and have them make > that decision again. Is it so difficult to make such a decision? The userland already knows what we are emulating. I'm afraid that in future we can end up in having 10 versions of KVM_EXIT_xxx_HYPERCALL with very small difference between them. Will it be good? Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia