From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43500)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1a9xM4-00015R-OG
	for qemu-devel@nongnu.org; Fri, 18 Dec 2015 10:54:05 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1a9xM1-0007Pn-GD
	for qemu-devel@nongnu.org; Fri, 18 Dec 2015 10:54:04 -0500
Received: from relay.parallels.com ([195.214.232.42]:52135)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1a9xM1-0007Pe-7H
	for qemu-devel@nongnu.org; Fri, 18 Dec 2015 10:54:01 -0500
References: <1447158995-21919-1-git-send-email-asmetanin@virtuozzo.com>
	<1447158995-21919-6-git-send-email-asmetanin@virtuozzo.com>
	<01cc01d139a7$7baad550$73007ff0$@samsung.com>
From: "Denis V. Lunev" <den@openvz.org>
Message-ID: <56742C05.4050907@openvz.org>
Date: Fri, 18 Dec 2015 18:53:41 +0300
MIME-Version: 1.0
In-Reply-To: <01cc01d139a7$7baad550$73007ff0$@samsung.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v4 5/5] kvm/x86: Hyper-V kvm exit
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Pavel Fedin <p.fedin@samsung.com>, 'Andrey Smetanin' <asmetanin@virtuozzo.com>, kvm@vger.kernel.org
Cc: 'Gleb Natapov' <gleb@kernel.org>, 'Paolo Bonzini' <pbonzini@redhat.com>, 'Roman Kagan' <rkagan@virtuozzo.com>, qemu-devel@nongnu.org

On 12/18/2015 06:19 PM, Pavel Fedin wrote:
>   Hello!
>
>   I realize that it's perhaps too late, because patches are already on Linux-next, but i have one concern... May be it's not too
> late...
>
>   I dislike implementing architecture-dependent exit code where we could implement an architecture-independent one.
>
>   As far as i understand this code, KVM_EXIT_HYPERV is called when one of three MSRs are accessed. But, shouldn't we have implemented
> instead something more generic, like KVM_EXIT_REG_IO, which would work similar to KVM_EXIT_PIO or KVM_EXIT_MMIO, but carry register
> code and value?
>
>   This would allow us to solve the same task which we have done here, but this solution would be reusable for other devices and other
> archirectures. What if in future we have more system registers to emulate in userspace?
>
>   I write this because at one point i suggested similar thing for ARM64 (but i never actually wrote it), to emulate physical CP15
> timer. And it would require exactly the same capability - process some trapped system register accesses in userspace.
>
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
>
>
we have discussed this AFAIR. HyperV guest implementation
is available in Linux kernel and thus technically we can have
this stuff on any platform.

Den