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