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.3 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 DE356C433DB for ; Thu, 28 Jan 2021 09:08:27 +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 502A164DD1 for ; Thu, 28 Jan 2021 09:08:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 502A164DD1 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=QX0Pr8OWnKpPsp306XZFLLoyp6oeZChsycPxVVOb+T4=; b=GeOAOJwMTr09kJlhfVPRUxRAn ylA9dkWVV+m8H57uOJLr3WDm8MYK7D4kcOjCnKnO5lpvMHNb9JmvALI7oY+08nP6HtVZO6kKznJ/C khUjhs+/zMU/pAKDyAgddh7jAcugZk9g/NgYgHl5Rf4fm22h6r7rFmO2rK1HfC7QDB2Xtq19gA29c mRqq9Dq/EpB6SLWUtJwNF3GEV4ExNrN4EGTea53POoctQmwsqBnUrq5uSAhNqfds8TnHzuKywloOc x5fajLT2Rk3iX0LKS1tHGNNvgROYNyLVPzg/M2JMGeU04ydDcjbUVte8I/9MtLppunA3RjR2haRPN JXo8vlUCg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l53Gn-0007M7-6Y; Thu, 28 Jan 2021 09:07:17 +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 1l53Gk-0007LR-OV for linux-arm-kernel@lists.infradead.org; Thu, 28 Jan 2021 09:07:15 +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 5E35664DD1; Thu, 28 Jan 2021 09:07:13 +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 1l53Gh-00AZZn-4I; Thu, 28 Jan 2021 09:07:11 +0000 MIME-Version: 1.0 Date: Thu, 28 Jan 2021 09:07:11 +0000 From: Marc Zyngier To: Jianyong Wu Subject: Re: [PATCH] arm64/kvm: correct the error report in kvm_handle_guest_abort In-Reply-To: References: <20210115093028.6504-1-jianyong.wu@arm.com> <6f5a2ce458e33f879635f45140293517@kernel.org> <73b606d9c49e05435113a40a534af133@kernel.org> User-Agent: Roundcube Webmail/1.4.10 Message-ID: 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-20210128_040714_974460_B8667132 X-CRM114-Status: GOOD ( 21.52 ) 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 , Steve Capper , Suzuki Poulose , James Morse , nd , 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-28 03:01, Jianyong Wu wrote: > Hi Marc, > >> >> From 8f2a919d6f13d36445974794c76821fbb6b40f88 Mon Sep 17 00:00:00 >> 2001 >> From: Marc Zyngier >> Date: Sat, 16 Jan 2021 10:53:21 +0000 >> Subject: [PATCH] CMO on RO memslot >> >> Signed-off-by: Marc Zyngier >> --- >> arch/arm64/kvm/mmu.c | 51 +++++++++++++++++++++++++++++++++---- >> ------- >> 1 file changed, 39 insertions(+), 12 deletions(-) >> >> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index >> 7d2257cc5438..3c176b5b0a28 100644 >> --- a/arch/arm64/kvm/mmu.c >> +++ b/arch/arm64/kvm/mmu.c >> @@ -760,7 +760,15 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, >> phys_addr_t fault_ipa, >> struct kvm_pgtable *pgt; >> >> fault_granule = 1UL << >> ARM64_HW_PGTABLE_LEVEL_SHIFT(fault_level); >> - write_fault = kvm_is_write_fault(vcpu); >> + /* >> + * Treat translation faults on CMOs as read faults. Should >> + * this further generate a permission fault, it will be caught >> + * in kvm_handle_guest_abort(), with prejudice... >> + */ >> + if (fault_status == FSC_FAULT && kvm_vcpu_dabt_is_cm(vcpu)) >> + write_fault = false; >> + else >> + write_fault = kvm_is_write_fault(vcpu); >> exec_fault = kvm_vcpu_trap_is_exec_fault(vcpu); >> VM_BUG_ON(write_fault && exec_fault); >> >> @@ -1013,19 +1021,37 @@ 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: >> + * >> + * - 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, check whether this is a permission fault. >> + * If so, that's a DC IVAC on a R/O memslot, which is a >> + * pretty bad idea, and we tell the guest so. >> * >> - * So let's assume that the guest is just being >> - * cautious, and skip the instruction. >> + * - If this wasn't a permission fault, pass it along for >> + * further handling (including faulting the page in >> if it >> + * was a translation fault). >> */ >> - if (kvm_is_error_hva(hva) && kvm_vcpu_dabt_is_cm(vcpu)) >> { >> - kvm_incr_pc(vcpu); >> - ret = 1; >> - goto out_unlock; >> + if (kvm_vcpu_dabt_is_cm(vcpu)) { >> + if (kvm_is_error_hva(hva)) { >> + kvm_incr_pc(vcpu); >> + ret = 1; >> + goto out_unlock; >> + } >> + >> + if (fault_status == FSC_PERM) { >> + /* DC IVAC on a R/O memslot */ >> + kvm_inject_dabt(vcpu, >> kvm_vcpu_get_hfar(vcpu)); > > One question: > In general, the "DC" ops show up very early in guest. So what if the > guest do this before interrupt initialization? If so, the guest may > stuck here. I don't understand your question. Do you mean "what if the guest does this without being able to handle an exception"? If that's your question, then the answer is "don't do that". The architecture is clear that DC IVAC needs write permission, and will result in an abort being delivered if there is no writable mapping (and there can't be, the memslot is R/O). DC CIVAC doesn't have that requirement, and will not generate an exception. Thanks, M. -- 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