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