From mboxrd@z Thu Jan 1 00:00:00 1970
From: Pavel Fedin
Subject: RE: [RFC PATCH 2/5] KVM: add KVM_EXIT_MSR exit reason and capability.
Date: Wed, 23 Dec 2015 10:47:12 +0300
Message-ID: <00d301d13d56$2336f0e0$69a4d2a0$@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>
<003701d13c89$c2d5e980$4881bc80$@samsung.com>
<20151222120106.GJ11808@rkaganb.sw.ru>
<006101d13cb7$88441520$98cc3f60$@samsung.com>
<20151222140945.GK11808@rkaganb.sw.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: 'Peter Hornyack' ,
'Paolo Bonzini' ,
'kvm list' ,
'Gleb Natapov' ,
'Joerg Roedel' ,
'Andrey Smetanin' ,
"'Denis V. Lunev'"
To: 'Roman Kagan'
Return-path:
Received: from mailout1.w1.samsung.com ([210.118.77.11]:15112 "EHLO
mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S933387AbbLWHrR (ORCPT );
Wed, 23 Dec 2015 02:47:17 -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 <0NZS007Z0WAP0Y50@mailout1.w1.samsung.com> for
kvm@vger.kernel.org; Wed, 23 Dec 2015 07:47:14 +0000 (GMT)
In-reply-to: <20151222140945.GK11808@rkaganb.sw.ru>
Content-language: ru
Sender: kvm-owner@vger.kernel.org
List-ID:
Hello!
> It has: unlike the scenario that was the original motivation for Peter's
> patches, where the the userspace wanted to handle register accesses
> which the kernel *didn't*, in case of SynIC the userspace wants do
> something about MSR accesses *only* if the kernel *also* handles them.
Well... I believe, that qemu knows if we are instantiating SynIC. And, if we are, it knows that the kernel will do something about
it. Otherwise these registers don't exist, and, by the way, the guest is not expected to touch them, is it?
> I guess that was the reason why Paolo suggested an extra exit_reason,
> and I think .handled field can be used to pass that information instead.
[skip]
> But the proposed use of .handled costs basically nothing, and it may
> prove useful in general (as a conisistency proof, if anything).
Well... May be... So, i'm OK with it.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia