From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 75C4612E75; Thu, 22 Aug 2024 15:14:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724339666; cv=none; b=ZgKvT8hf1c6dQEqftfFPibH7V8g2kKlPGdkBYEaCAWfmT8ioaWgTRN8aZ8RbzrPoEr8welU22OMMsPt9thhc6CM80T61yuz7JIH4OkPiSWUm2pTxSA24ZTjKP4ZsGmO6lqP0IS+IHuL7VdRjTou8iqOJHugo6tBYW1dhRcWcWZQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724339666; c=relaxed/simple; bh=Z0x+iQbZGRupwKlqBCAsGrzbaayYp2vs4jBrbc+BHTI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=JLuWTz7M/AUMSM5kQDyeisdZsXE/dSa7EOJWYZ+HwpiD7MbsN7noVWuxY3+ASZadiJuLq0uo65LOyB45yf2W5bx81bg8Ce0mUJYkWFlmapROmwT6KX+6K/HQ45FL7Np5QJH7WdbGmqNWJZAk1p+pAY/s7IAYlkzTqFyoz6kv38Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DB36F169E; Thu, 22 Aug 2024 08:14:50 -0700 (PDT) Received: from [10.57.85.214] (unknown [10.57.85.214]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 58C693F58B; Thu, 22 Aug 2024 08:14:20 -0700 (PDT) Message-ID: <8c0f787c-35d4-4cb1-84d3-ff3f2e3f003a@arm.com> Date: Thu, 22 Aug 2024 16:14:18 +0100 Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 21/43] arm64: RME: Runtime faulting of memory To: "Aneesh Kumar K.V" , kvm@vger.kernel.org, kvmarm@lists.linux.dev Cc: 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 References: <20240821153844.60084-1-steven.price@arm.com> <20240821153844.60084-22-steven.price@arm.com> From: Steven Price Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22/08/2024 04:32, Aneesh Kumar K.V wrote: > Steven Price writes: > >> At runtime if the realm guest accesses memory which hasn't yet been >> mapped then KVM needs to either populate the region or fault the guest. >> >> For memory in the lower (protected) region of IPA a fresh page is >> provided to the RMM which will zero the contents. For memory in the >> upper (shared) region of IPA, the memory from the memslot is mapped >> into the realm VM non secure. >> >> Signed-off-by: Steven Price >> --- >> Changes since v2: >> * Avoid leaking memory if failing to map it in the realm. >> * Correctly mask RTT based on LPA2 flag (see rtt_get_phys()). >> * Adapt to changes in previous patches. >> > > .... > >> - gfn = ipa >> PAGE_SHIFT; >> + gfn = (ipa & ~gpa_stolen_mask) >> PAGE_SHIFT; >> memslot = gfn_to_memslot(vcpu->kvm, gfn); >> + >> + if (kvm_slot_can_be_private(memslot)) { >> + ret = private_memslot_fault(vcpu, fault_ipa, memslot); >> + if (ret != -EAGAIN) >> + goto out; >> + } >> > > Shouldn't this be s/fault_ipa/ipa ? Well they should both be the same unless we're in some scary parallel universe where we have nested virtualisation *and* realms at the same time (shudder!). But yes "ipa" would be more consistent so I'll change it! Steve > ret = private_memslot_fault(vcpu, ipa, memslot); > > -aneesh