From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40102) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLzx0-000565-UU for qemu-devel@nongnu.org; Wed, 20 Jan 2016 16:05:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLzwx-0006RW-N0 for qemu-devel@nongnu.org; Wed, 20 Jan 2016 16:05:58 -0500 Received: from mail-wm0-x242.google.com ([2a00:1450:400c:c09::242]:33743) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLzwx-0006Qn-GW for qemu-devel@nongnu.org; Wed, 20 Jan 2016 16:05:55 -0500 Received: by mail-wm0-x242.google.com with SMTP id u188so6649433wmu.0 for ; Wed, 20 Jan 2016 13:05:55 -0800 (PST) Sender: Paolo Bonzini References: <1452595842-20880-1-git-send-email-asmetanin@virtuozzo.com> <1452595842-20880-5-git-send-email-asmetanin@virtuozzo.com> <009401d14ea5$dc8cf250$95a6d6f0$@samsung.com> <569F92AC.4030506@redhat.com> <20160120152034.GA3947@rkaganb.sw.ru> <569FBDA1.7010704@redhat.com> <20160120173106.GJ26969@rkaganb.sw.ru> From: Paolo Bonzini Message-ID: <569FF6AF.5010302@redhat.com> Date: Wed, 20 Jan 2016 22:05:51 +0100 MIME-Version: 1.0 In-Reply-To: <20160120173106.GJ26969@rkaganb.sw.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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' , Pavel Fedin , 'Andrey Smetanin' , kvm@vger.kernel.org, 'Gleb Natapov' , 'Joerg Roedel' , "'K. Y. Srinivasan'" , 'Haiyang Zhang' , "'Denis V. Lunev'" , qemu-devel@nongnu.org On 20/01/2016 18:31, 'Roman Kagan' wrote: > On Wed, Jan 20, 2016 at 06:02:25PM +0100, Paolo Bonzini wrote: >> >> >> On 20/01/2016 16:20, 'Roman Kagan' wrote: >>>>> So we should not add a new exit >>> Why? VCPU exit codes are not a scarse resource. >> >> Indeed, but grouping makes things easier to understand. >> >>> So far we've envisaged two reasons for VCPU exit related to hyper-v: one >>> for hyper-v MSRs and the other for hypercalls. Since there was a >>> discussion on implementing generic MSR access by Peter we thought it >>> wiser to introduce a new VCPU exit for hyper-v hypercalls to avoid >>> interfering with the MSR implementation. >> >> That's a good idea. However, I think I'm not going to accept the MSR >> exit feature, and then the current Hyper-V exit API makes some sense >> indeed (it's just 3 values, transferring them all at once is not >> expensive at all). > > OK can we please sum up (as I'm now a bit confused) what we do now: > > 1) use a single vcpu exit for both Hyper-V cases (which implies we need > to fix this patchset to add the subcode for hypercalls) This. Paolo > or > > 2) use individual vcpu exits for Hyper-V MSRs and for Hyper-V hypercalls > (which implies we need to submit an incremental patch dropping the > subcode from Hyper-V MSR exit and renaming it to better describe the > reality)? > > Thanks, > Roman. > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >