From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DEB80C433E0 for ; Fri, 15 Jan 2021 11:22:24 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 94B432371F for ; Fri, 15 Jan 2021 11:22:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 94B432371F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=o0NqqsGJysTIZMXHBcEYqR3Drv4A102eN2k4SjT2CU4=; b=mu1mF2VLugjHLfXMN3XrsRczV 948w4XmJZ3bQXN4a4YPAS0fiKn3kutAfV4A6o2XZlnIAgzoW+u6WqjP3pOmXSYchrWP+skliBJRr5 1kO606ScVRbPLdxaqGf7q7Vg8b1GvQ/ldC8JYMwkEAgfxosTxNSo8idRccaq8reeXKs78AAj11fPZ /zbY8+XgmX9Sk+HuEQU3tmsmnMzhMsDRkJX5z5C6/o32g7tfi/6fW3PqNSrGT9/YywXpJ3XvmRrVh C3T5wwvFNcybv3tU9wJbOkiXMfPRqi1msSVIII0qkCMDkAl2B6b0Bl8gCh6sS7SDD0q0EeO9mW7sT Ii4CRs94g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0NA0-0008Ky-00; Fri, 15 Jan 2021 11:20:56 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0N9t-0008KE-L9 for linux-arm-kernel@lists.infradead.org; Fri, 15 Jan 2021 11:20:54 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 885A62371F; Fri, 15 Jan 2021 11:20:48 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1l0N9q-007iyv-BK; Fri, 15 Jan 2021 11:20:46 +0000 MIME-Version: 1.0 Date: Fri, 15 Jan 2021 11:20:46 +0000 From: Marc Zyngier To: Jianyong Wu Subject: Re: [PATCH] arm64/kvm: correct the error report in kvm_handle_guest_abort In-Reply-To: <20210115093028.6504-1-jianyong.wu@arm.com> References: <20210115093028.6504-1-jianyong.wu@arm.com> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <6f5a2ce458e33f879635f45140293517@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: jianyong.wu@arm.com, james.morse@arm.com, will@kernel.org, suzuki.poulose@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, Steve.Capper@arm.com, justin.he@arm.com, nd@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210115_062049_837349_94DA63C5 X-CRM114-Status: GOOD ( 25.88 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: justin.he@arm.com, Steve.Capper@arm.com, suzuki.poulose@arm.com, james.morse@arm.com, nd@arm.com, will@kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2021-01-15 09:30, Jianyong Wu wrote: > Currently, error report when cache maintenance at read-only memory > range, > like rom, is not clear enough and even not correct. As the specific > error > is definitely known by kvm, it is obliged to give it out. > > Fox example, in a qemu/kvm VM, if the guest do dc at the pflash range > from > 0 to 128M, error is reported by kvm as "Data abort outside memslots > with > no valid syndrome info" which is not quite correct. > > Signed-off-by: Jianyong Wu > --- > arch/arm64/kvm/mmu.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index 7d2257cc5438..de66b7e38a5b 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -1022,9 +1022,15 @@ int kvm_handle_guest_abort(struct kvm_vcpu > *vcpu) > * So let's assume that the guest is just being > * cautious, and skip the instruction. > */ > - if (kvm_is_error_hva(hva) && kvm_vcpu_dabt_is_cm(vcpu)) { > - kvm_incr_pc(vcpu); > - ret = 1; > + if (kvm_vcpu_dabt_is_cm(vcpu)) { > + if (kvm_is_error_hva(hva)) { > + kvm_incr_pc(vcpu); > + ret = 1; > + goto out_unlock; > + } > + > + kvm_err("Do cache maintenance in the read-only memory range\n"); We don't scream on the console for guests bugs. > + ret = -EFAULT; > goto out_unlock; > } And what is userspace going to do with that? To be honest, I'd rather not report it in any case: - either it isn't mapped, and there is no cache to clean/invalidate - or it is mapped read-only: - if it is a "DC IVAC", the guest should get the fault as per the ARM ARM. But I don't think we can identify the particular CMO at this stage, so actually performing an invalidation is the least bad thing to do. How about this (untested)? M. diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index 7d2257cc5438..0f497faad131 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -1013,16 +1013,27 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu) } /* - * Check for a cache maintenance operation. Since we - * ended-up here, we know it is outside of any memory - * slot. But we can't find out if that is for a device, - * or if the guest is just being stupid. The only thing - * we know for sure is that this range cannot be cached. + * Check for a cache maintenance operation. Two cases: * - * So let's assume that the guest is just being - * cautious, and skip the instruction. + * - It is outside of any memory slot. But we can't + * find out if that is for a device, or if the guest + * is just being stupid. The only thing we know for + * sure is that this range cannot be cached. So + * let's assume that the guest is just being + * cautious, and skip the instruction. + * + * - Otherwise, clean/invalidate the whole memslot. We + * should special-case DC IVAC and inject a + * permission fault, but we can't really identify it + * in this context. */ - if (kvm_is_error_hva(hva) && kvm_vcpu_dabt_is_cm(vcpu)) { + if (kvm_vcpu_dabt_is_cm(vcpu)) { + if (!kvm_is_error_hva(hva)) { + spin_lock(&vcpu->kvm->mmu_lock); + stage2_flush_memslot(vcpu->kvm, memslot); + spin_unlock(&vcpu->kvm->mmu_lock); + } + kvm_incr_pc(vcpu); ret = 1; goto out_unlock; -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel