From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933839AbdBVWlu (ORCPT ); Wed, 22 Feb 2017 17:41:50 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:46793 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932433AbdBVWll (ORCPT ); Wed, 22 Feb 2017 17:41:41 -0500 From: Christian Borntraeger Subject: Re: [PATCH 4/5] KVM: add __kvm_request_needs_mb To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , David Hildenbrand References: <20170216160449.13094-1-rkrcmar@redhat.com> <20170216160449.13094-5-rkrcmar@redhat.com> <865e0ec3-6918-5372-0c85-af2181209749@redhat.com> <35bdb122-3783-91b1-56b5-27bda4c923ad@de.ibm.com> <7f521412-1e8f-e519-1274-5db3ec7d36b8@redhat.com> <20170222151704.GA3856@potion> Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Paolo Bonzini , Andrew Jones , Marc Zyngier , Cornelia Huck , James Hogan , Paul Mackerras , Christoffer Dall Date: Wed, 22 Feb 2017 20:57:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170222151704.GA3856@potion> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17022219-0016-0000-0000-0000063F3984 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006664; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000204; SDB=6.00825633; UDB=6.00404281; IPR=6.00603088; BA=6.00005166; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014397; XFM=3.00000011; UTC=2017-02-22 19:57:16 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17022219-0017-0000-0000-000037A117F0 Message-Id: <8960b809-0faa-58e5-4839-b28a09f161d6@de.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-22_12:,, 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-1612050000 definitions=main-1702220179 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/22/2017 04:17 PM, Radim Krčmář wrote: > [...] > while (vcpu->arch.sie_block->prog0c & PROG_IN_SIE) > cpu_relax(); > } > And out of curiosity -- how many cycles does this loop usually take? A quick hack indicates something between 3 and 700ns. >> 2. Remote requests that don't need a sync >> >> E.g. KVM_REQ_ENABLE_IBS doesn't strictly need it, while >> KVM_REQ_DISABLE_IBS does. > > A usual KVM request would kick the VCPU out of nested virt as well. > Shouldn't it be done for these as well? A common code function probably should. For some of the cases (again prefix page handling) we do not need it. For example if we unmap the guest prefix page, but guest^2 is running this causes no trouble as long as we handle the request before reentering guest^1. So not an easy answer. > >> 3. local requests >> >> E.g. KVM_REQ_TLB_FLUSH from kvm_s390_set_prefix() >> >> >> Of course, having a unified interface would be better. >> >> /* set the request and kick the CPU out of guest mode */ >> kvm_set_request(req, vcpu); >> >> /* set the request, kick the CPU out of guest mode, wait until guest >> mode has been left and make sure the request will be handled before >> reentering guest mode */ >> kvm_set_sync_request(req, vcpu); > > Sounds good, I'll also add > > kvm_set_self_request(req, vcpu); > >> Same maybe even for multiple VCPUs (as there are then ways to speed it >> up, e.g. first kick all, then wait for all) >> >> This would require arch specific callbacks to >> 1. pre announce the request (e.g. set PROG_REQUEST on s390x) >> 2. kick the cpu (e.g. CPUSTAT_STOP_INT and later >> kvm_s390_vsie_kick(vcpu) on s390x) >> 3. check if still executing the guest (e.g. PROG_IN_SIE on s390x) >> >> This would only make sense if there are other use cases for sync >> requests. At least I remember that Power also has a faster way for >> kicking VCPUs, not involving SMP rescheds. I can't judge if this is a >> s390x only thing and is better be left as is :) >> >> At least vcpu_kick() could be quite easily made to work on s390x. >> >> Radim, are there also other users that need something like sync requests? > > I think that ARM has a similar need when updating vgic, but relies on an > asumption that VCPUs are going to be out after kicking them with > kvm_make_all_cpus_request(). > (vgic_change_active_prepare in virt/kvm/arm/vgic/vgic-mmio.c) > > Having synchronous requests in a common API should probably wait for the > completion of the request, not just for the kick, which would make race > handling simpler. This would be problematic for our prefix page handling due to locking.