From mboxrd@z Thu Jan 1 00:00:00 1970 From: 'Roman Kagan' Subject: Re: [PATCH v1 4/5] kvm/x86: Hyper-V VMBus hypercall userspace exit Date: Thu, 14 Jan 2016 14:52:23 +0300 Message-ID: <20160114115221.GB10363@rkaganb.sw.ru> 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> <00b201d14eb9$5d8ddeb0$18a99c10$@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: 'Andrey Smetanin' , , "'Gleb Natapov'" , 'Paolo Bonzini' , "'Joerg Roedel'" , "'K. Y. Srinivasan'" , "'Haiyang Zhang'" , "'Denis V. Lunev'" , To: Pavel Fedin Return-path: Received: from relay.parallels.com ([195.214.232.42]:38416 "EHLO relay.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751010AbcANLwr (ORCPT ); Thu, 14 Jan 2016 06:52:47 -0500 Content-Disposition: inline In-Reply-To: <00b201d14eb9$5d8ddeb0$18a99c10$@samsung.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jan 14, 2016 at 01:50:20PM +0300, Pavel Fedin wrote: > > 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. ... and you get something in the registers on return (all that is from guest POV). Right. The differences are, however, which registers are used for parameters and return values, how they are encoded, etc. > So, you just need to pass registers in your structure. Which ones? This is going to be hypervisor- and arch-specific. > Or, you could even use generic register access APIs. With an extra ioctl? This is going to be expensive. > > 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. It isn't terribly difficult, but KVM has to do all that already, as it handles some of the hypercalls in the kernel. I don't think duplicating this (and also designing a generic marshalling scheme) is profitable compared to saving a vcpu exit code. > 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? I don't see it to be a problem. Roman. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52240) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJgSP-0002bb-FP for qemu-devel@nongnu.org; Thu, 14 Jan 2016 06:52:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJgSM-000528-7L for qemu-devel@nongnu.org; Thu, 14 Jan 2016 06:52:49 -0500 Received: from relay.parallels.com ([195.214.232.42]:34132) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJgSL-00051X-VL for qemu-devel@nongnu.org; Thu, 14 Jan 2016 06:52:46 -0500 Date: Thu, 14 Jan 2016 14:52:23 +0300 From: 'Roman Kagan' Message-ID: <20160114115221.GB10363@rkaganb.sw.ru> 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> <00b201d14eb9$5d8ddeb0$18a99c10$@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <00b201d14eb9$5d8ddeb0$18a99c10$@samsung.com> 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: Pavel Fedin 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' On Thu, Jan 14, 2016 at 01:50:20PM +0300, Pavel Fedin wrote: > > 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. ... and you get something in the registers on return (all that is from guest POV). Right. The differences are, however, which registers are used for parameters and return values, how they are encoded, etc. > So, you just need to pass registers in your structure. Which ones? This is going to be hypervisor- and arch-specific. > Or, you could even use generic register access APIs. With an extra ioctl? This is going to be expensive. > > 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. It isn't terribly difficult, but KVM has to do all that already, as it handles some of the hypercalls in the kernel. I don't think duplicating this (and also designing a generic marshalling scheme) is profitable compared to saving a vcpu exit code. > 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? I don't see it to be a problem. Roman.