From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932725AbcI3JcO (ORCPT ); Fri, 30 Sep 2016 05:32:14 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:36496 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932616AbcI3JcD (ORCPT ); Fri, 30 Sep 2016 05:32:03 -0400 Subject: Re: [PATCH v3 0/4] implement vcpu preempted check To: Paolo Bonzini References: <1469101514-49475-1-git-send-email-xinhui.pan@linux.vnet.ibm.com> <20160929101040.GV5016@twins.programming.kicks-ass.net> <166f3bad-f700-4624-6c1c-996f90ad609c@de.ibm.com> <20160929103133.GW5016@twins.programming.kicks-ass.net> <496ba299-1f1d-e98b-7827-f861eeea5558@linux.vnet.ibm.com> <2136938368.606190.1475218738567.JavaMail.zimbra@redhat.com> Cc: Peter Zijlstra , Christian Borntraeger , Pan Xinhui , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, virtualization@lists.linux-foundation.org, linux-s390@vger.kernel.org, xen-devel-request@lists.xenproject.org, kvm@vger.kernel.org, benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, mingo@redhat.com, paulmck@linux.vnet.ibm.com, will deacon , kernellwp@gmail.com, jgross@suse.com, bsingharora@gmail.com, Heiko Carstens From: Pan Xinhui Date: Fri, 30 Sep 2016 17:31:48 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16093009-0016-0000-0000-000004D03F4D X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005830; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000186; SDB=6.00763016; UDB=6.00363791; IPR=6.00538164; BA=6.00004773; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012828; XFM=3.00000011; UTC=2016-09-30 09:32:00 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16093009-0017-0000-0000-00003364A97C Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-09-30_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609280000 definitions=main-1609300172 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2016/9/30 17:08, Paolo Bonzini 写道: > > > On 30/09/2016 10:52, Pan Xinhui wrote: >>> x86 has no hypervisor support, and I'd like to understand the desired >>> semantics first, so I don't think it should block this series. In >> >> Once a guest do a hypercall or something similar, IOW, there is a >> kvm_guest_exit. we think this is a lock holder preemption. >> Adn PPC implement it in this way. > > Ok, good. > >>> particular, there are at least the following choices: >>> >>> 1) exit to userspace (5-10.000 clock cycles best case) counts as >>> lock holder preemption >>> >>> 2) any time the vCPU thread not running counts as lock holder >>> preemption >>> >>> To implement the latter you'd need a hypercall or MSR (at least as >>> a slow path), because the KVM preempt notifier is only active >>> during the KVM_RUN ioctl. >> >> seems a little expensive. :( >> How many clock cycles it might cost. > > An MSR read is about 1500 clock cycles, but it need not be the fast path > (e.g. use a bit to check if the CPU is running, if not use the MSR to > check if the CPU is in userspace but the CPU thread is scheduled). But > it's not necessary if you are just matching PPC semantics. > > Then the simplest thing is to use the kvm_steal_time struct, and add a > new field to it that replaces pad[0]. You can write a 0 to the flag in > record_steal_time (not preempted) and a 1 in kvm_arch_vcpu_put > (preempted). record_steal_time is called before the VM starts running, > immediately after KVM_RUN and also after every sched_in. > > If KVM doesn't implement the flag, it won't touch that field at all. So > the kernel can write a 0, meaning "not preempted", and not care if the > hypervisor implements the flag or not: the answer will always be safe. > > The pointer to the flag can be placed in a per-cpu u32*, and again if > the u32* is NULL that means "not preempted". > really nice suggestion! That's what I want :) thanks xinhui > Paolo > > >> I am still looking for one shared struct between kvm and guest kernel on >> x86. >> and every time kvm_guest_exit/enter called, we store some info in it. So >> guest kernel can check one vcpu is running or not quickly. >> >> thanks >> xinhui >> >>> Paolo >>> >> >