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: Wed, 20 Jan 2016 18:20:35 +0300 Message-ID: <20160120152034.GA3947@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> <569F92AC.4030506@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Pavel Fedin , 'Andrey Smetanin' , , 'Gleb Natapov' , 'Joerg Roedel' , "'K. Y. Srinivasan'" , 'Haiyang Zhang' , "'Denis V. Lunev'" , To: Paolo Bonzini Return-path: Received: from mx2.parallels.com ([199.115.105.18]:60318 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932744AbcATPU6 (ORCPT ); Wed, 20 Jan 2016 10:20:58 -0500 Content-Disposition: inline In-Reply-To: <569F92AC.4030506@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jan 20, 2016 at 02:59:08PM +0100, Paolo Bonzini wrote: > >> --- a/Documentation/virtual/kvm/api.txt > >> +++ b/Documentation/virtual/kvm/api.txt > >> @@ -3359,6 +3359,14 @@ Hyper-V SynIC state change. Notification is used to remap SynIC > >> event/message pages and to enable/disable SynIC messages/events processing > >> in userspace. > >> > >> + /* KVM_EXIT_HYPERV_HCALL */ > >> + struct { > >> + __u64 input; > >> + __u64 params[2]; > >> + __u64 result; > >> + } hv_hcall; > >> +Indicates that the VCPU exits into userspace to process some guest > >> +Hyper-V hypercalls. > > > > Why introducing this? We already have KVM_EXIT_HYPERCALL, which is > > exactly the same. AFAIK it's not used at the moment. > > Additionally, in theory we could have hypercalls handled in > > userspace for something else except HyperV. And not only for x86. > > 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)? 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. > (I suggested elsewhere the existing hyper-v exit) 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. Thanks, Roman. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLuZ9-0001fN-C4 for qemu-devel@nongnu.org; Wed, 20 Jan 2016 10:21:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLuZ6-0000Hx-6P for qemu-devel@nongnu.org; Wed, 20 Jan 2016 10:20:59 -0500 Received: from mx2.parallels.com ([199.115.105.18]:46418) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLuZ6-0000Hq-14 for qemu-devel@nongnu.org; Wed, 20 Jan 2016 10:20:56 -0500 Date: Wed, 20 Jan 2016 18:20:35 +0300 From: 'Roman Kagan' Message-ID: <20160120152034.GA3947@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> <569F92AC.4030506@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <569F92AC.4030506@redhat.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: Paolo Bonzini Cc: kvm@vger.kernel.org, 'Gleb Natapov' , 'Joerg Roedel' , Pavel Fedin , qemu-devel@nongnu.org, 'Andrey Smetanin' , "'Denis V. Lunev'" , "'K. Y. Srinivasan'" , 'Haiyang Zhang' On Wed, Jan 20, 2016 at 02:59:08PM +0100, Paolo Bonzini wrote: > >> --- a/Documentation/virtual/kvm/api.txt > >> +++ b/Documentation/virtual/kvm/api.txt > >> @@ -3359,6 +3359,14 @@ Hyper-V SynIC state change. Notification is used to remap SynIC > >> event/message pages and to enable/disable SynIC messages/events processing > >> in userspace. > >> > >> + /* KVM_EXIT_HYPERV_HCALL */ > >> + struct { > >> + __u64 input; > >> + __u64 params[2]; > >> + __u64 result; > >> + } hv_hcall; > >> +Indicates that the VCPU exits into userspace to process some guest > >> +Hyper-V hypercalls. > > > > Why introducing this? We already have KVM_EXIT_HYPERCALL, which is > > exactly the same. AFAIK it's not used at the moment. > > Additionally, in theory we could have hypercalls handled in > > userspace for something else except HyperV. And not only for x86. > > 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)? 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. > (I suggested elsewhere the existing hyper-v exit) 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. Thanks, Roman.