From mboxrd@z Thu Jan  1 00:00:00 1970
From: Pavel Fedin <p.fedin@samsung.com>
Subject: RE: [RFC PATCH 2/5] KVM: add KVM_EXIT_MSR exit reason and capability.
Date: Tue, 22 Dec 2015 15:51:52 +0300
Message-ID: <006101d13cb7$88441520$98cc3f60$@samsung.com>
References: <1439923615-10600-1-git-send-email-peterhornyack@google.com>
 <1439923615-10600-3-git-send-email-peterhornyack@google.com>
 <567479DE.6010805@redhat.com>
 <CA+0KQ4P1M6mb8-BtKg9Ss5PRk5ZAqPRLZ1WwkQzuHhHbFturKg@mail.gmail.com>
 <003701d13c89$c2d5e980$4881bc80$@samsung.com>
 <20151222120106.GJ11808@rkaganb.sw.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: 'Peter Hornyack' <peterhornyack@google.com>,
	'Paolo Bonzini' <pbonzini@redhat.com>,
	'kvm list' <kvm@vger.kernel.org>,
	'Gleb Natapov' <gleb@kernel.org>,
	'Joerg Roedel' <joro@8bytes.org>,
	'Andrey Smetanin' <asmetanin@virtuozzo.com>,
	"'Denis V. Lunev'" <den@openvz.org>
To: 'Roman Kagan' <rkagan@virtuozzo.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mailout4.w1.samsung.com ([210.118.77.14]:10073 "EHLO
	mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751732AbbLVMv4 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 22 Dec 2015 07:51:56 -0500
Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245])
 by mailout4.w1.samsung.com
 (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May  5 2014))
 with ESMTP id <0NZR00DSFFQHKC50@mailout4.w1.samsung.com> for
 kvm@vger.kernel.org; Tue, 22 Dec 2015 12:51:53 +0000 (GMT)
In-reply-to: <20151222120106.GJ11808@rkaganb.sw.ru>
Content-language: ru
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

 Hello!

> > 1. Is there any real need to distinguish between KVM_EXIT_MSR_WRITE and
> KVM_EXIT_MSR_AFTER_WRITE ? IMHO from userland's point of view these are the same.
> 
> Indeed.  Perhaps the kernel can set .handled to true to let userspace
> know it already took care of it, instead of introducing yet another
> exit_reason.  The field would need to be marked in/out, then.

 I'm not sure that you need even this. Anyway, particular MSRs are function-specific, and if you're emulating an MSR in userspace,
then, i believe, you know the function behind it. And it's IMHO safe to just know that SynIC MSRs have some extra handling in
kernel. And i believe this has no direct impact on userland's behavior.
 But, you better know the details.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia