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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AA702D1CDA1 for ; Tue, 22 Oct 2024 05:47:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ZDbU1LhM4/tXErZvFqRqfvT5c3gIplh+d5329aXS+A0=; b=btxQ7yUl5vT2S7g+eKcL363q40 662Cyqu7aEJ4IjBuAxB9ZUbk76KBzbpnAMD/QTMdAZ2nrLNK98STGAHY01eYeZFG0N/lPO3MeNwd2 BfV2eblxQjS6C9673Z6Oes4+0Nh1tocQNbg7+wiwEneHWF4MFHXp9HXm12BfKR+zdjcBVIDaCSjgZ /TwSewMKTsr+EEnmjTQxBj9TWh5dlLEe9TZpxumZmhsgeYv+f86ZsqqKD2SqyrwPk1PfVBMph4Utl Nw3A4jki9xuQpo2kEfZeRr//XBZl6zr9i37plHnLcFiQEN3y+2LY1bedH1ELA/HfMfeJSg/Ax8W8r /vhHahFg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t37kC-00000009i8b-3XdZ; Tue, 22 Oct 2024 05:47:48 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t37ZK-00000009gBV-25p5 for linux-arm-kernel@lists.infradead.org; Tue, 22 Oct 2024 05:36:35 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id EEEC15C5CF4; Tue, 22 Oct 2024 05:36:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 47947C4CEC3; Tue, 22 Oct 2024 05:36:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729575393; bh=wAQmJk9sBaDF/4frCO1dXVeeLAsFYnKWPlj3F8H/kGI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Wik+Y5JZKk4RYdo+5dTY2Sie/7AE3Z7z5mLERcY+v1MbvBoY8jhxYXo/q/t/NVDt0 pdZiy1wHdZLSgbg2cOsKWRkPYvpBvXkeEsiVZHLpJMZ3jzHSdz7nXix1otQC7Onoz3 6GWMxtXl4AV43+NE5ASm51YojalbuHX0/OicwA6A3Q1T4JbnxmapYXfJDNrsuKwdy5 tom+fdCIEduju3mm6RpHgpn0CQOJPGc/lh3750wBNRH/S7S3u5Q/QM+1qTqAauQbTP etB+nlKuTErT9/BjQ3BL6ZyU05lNccjQ7nPE/QJSNrAIoe/v0NpnTpNBxfpjbP382d 4+Mlb3JKv6L4w== X-Mailer: emacs 31.0.50 (via feedmail 11-beta-1 I) From: Aneesh Kumar K.V To: Steven Price , kvm@vger.kernel.org, kvmarm@lists.linux.dev Cc: Steven Price , Catalin Marinas , Marc Zyngier , Will Deacon , James Morse , Oliver Upton , Suzuki K Poulose , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Gavin Shan , Shanker Donthineni , Alper Gun Subject: Re: [PATCH v5 21/43] arm64: RME: Runtime faulting of memory In-Reply-To: <20241004152804.72508-22-steven.price@arm.com> References: <20241004152804.72508-1-steven.price@arm.com> <20241004152804.72508-22-steven.price@arm.com> Date: Tue, 22 Oct 2024 11:06:15 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241021_223634_607126_F88A7D7E X-CRM114-Status: GOOD ( 14.55 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org .... > +static int private_memslot_fault(struct kvm_vcpu *vcpu, > + phys_addr_t fault_ipa, > + struct kvm_memory_slot *memslot) > +{ > + struct kvm *kvm = vcpu->kvm; > + gpa_t gpa = kvm_gpa_from_fault(kvm, fault_ipa); > + gfn_t gfn = gpa >> PAGE_SHIFT; > + bool priv_exists = kvm_mem_is_private(kvm, gfn); > + struct kvm_mmu_memory_cache *memcache = &vcpu->arch.mmu_page_cache; > + kvm_pfn_t pfn; > + int ret; > + /* > + * For Realms, the shared address is an alias of the private GPA with > + * the top bit set. Thus is the fault address matches the GPA then it > + * is the private alias. > + */ > + bool is_priv_gfn = (gpa == fault_ipa); > + > + if (priv_exists != is_priv_gfn) { > + kvm_prepare_memory_fault_exit(vcpu, > + gpa, > + PAGE_SIZE, > + kvm_is_write_fault(vcpu), > + false, is_priv_gfn); > + > + return -EFAULT; > + } > If we want an exit to VMM and handle the fault, should we have the return value 0? For kvmtool we do have the KVM_RUN ioctl doing the below err = ioctl(vcpu->vcpu_fd, KVM_RUN, 0); if (err < 0 && (errno != EINTR && errno != EAGAIN)) die_perror("KVM_RUN failed"); Qemu did end up adding the below condition. if (!(run_ret == -EFAULT && run->exit_reason == KVM_EXIT_MEMORY_FAULT)) { fprintf(stderr, "error: kvm run failed %s\n", strerror(-run_ret)); so should we fix kvmtool. We may possibly want to add other exit_reason and it would be useful to not require similar VMM changes for these exit_reason. > + > + if (!is_priv_gfn) { > + /* Not a private mapping, handling normally */ > + return -EINVAL; > + } > + -aneesh