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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1002CD4958 for ; Thu, 21 Sep 2023 05:52:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0AAAC6B0191; Thu, 21 Sep 2023 01:52:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 05B166B0192; Thu, 21 Sep 2023 01:52:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E65376B0196; Thu, 21 Sep 2023 01:52:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D8F676B0191 for ; Thu, 21 Sep 2023 01:52:00 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A7628B4374 for ; Thu, 21 Sep 2023 05:52:00 +0000 (UTC) X-FDA: 81259533600.05.FAAAE5F Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by imf17.hostedemail.com (Postfix) with ESMTP id E94F040011 for ; Thu, 21 Sep 2023 05:51:57 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=BO2MAjtx; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf17.hostedemail.com: domain of binbin.wu@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=binbin.wu@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695275518; a=rsa-sha256; cv=none; b=uV1ntOnjG3Il087cnPuP0I2t/JR8GufJ0Vx4Qa9Tm/qZlRYJT9J5YVp0EVIrCasDvQPrYl kjMmUy+H+cCIsPUcgOki2XFHv9jASaHUL/05l34ojKWTkVLUjIk8qcQfHXE4zC/X92re5q ks9O+qoA9RPeWYdSwdmWRyoZKqwkWo0= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=BO2MAjtx; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf17.hostedemail.com: domain of binbin.wu@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=binbin.wu@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695275518; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nkQTuxjhazYmpd2iqZ0QL+SM/k8TtTi9frGjKqTCP/8=; b=KQUecZC4LWYQWvLwFO17V2f6pb/wwa+1g6kJwwsLu0lk5dDT+hkFh2RHpUzbm2kZJubMkI SThGJx/XDwH8dwJ2qnQy96WSQFb79FVZEnoetpHjkrFCCfuReGxa0RDN/mJo+aI63dy7D6 AUuUff6Oi+O3Br7Llh1gQpkFlCqUWao= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695275518; x=1726811518; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=oZ26NaKC2zv5YONE8y6jW8KHDfibqQbE4Lcj557476A=; b=BO2MAjtx4/yxLQO9PtboCLh5cWIM9K5SHggGImPgPzr746vyAtUepBGK xdEanoareKUxyRKXVsiCx9CSrRuxu/vDNjhSdNK6Y1x8scoake9FaOGL5 asQhOUfrBlsTO9Z+cba3ZFvLPjKk7HQ5ne4D/e45oaOtnUorn0o0LB4p3 eHqQ/iTpcsLZyxx0eHq4P861B4pB0XqXlhqdPiCrFa0ozKs4ZiuJ+rVCm f7IsYQYc3/9x2036e9/unk6f3eldwo3cPx56ZVJ4EGNbbujqdnWDuRth2 hCcVN8y1/Y8QjMQyFSUu5Y9mVmxqjAc7ZaCus4R/iaQ5RwgKQ2IG/XDRJ w==; X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="466734481" X-IronPort-AV: E=Sophos;i="6.03,164,1694761200"; d="scan'208";a="466734481" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Sep 2023 22:51:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="837187245" X-IronPort-AV: E=Sophos;i="6.03,164,1694761200"; d="scan'208";a="837187245" Received: from binbinwu-mobl.ccr.corp.intel.com (HELO [10.93.17.222]) ([10.93.17.222]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Sep 2023 22:51:36 -0700 Message-ID: Date: Thu, 21 Sep 2023 13:51:34 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [RFC PATCH v12 18/33] KVM: x86/mmu: Handle page fault for private memory To: Sean Christopherson , Yan Zhao Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , Yu Zhang , Isaku Yamahata , Xu Yilun , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-19-seanjc@google.com> From: Binbin Wu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: E94F040011 X-Stat-Signature: bn99ofessq8jhayxwwzkhbayjutrun84 X-HE-Tag: 1695275517-560898 X-HE-Meta: U2FsdGVkX18InZ8hdOpK4h92576G/Aa29KXyI6g2Hklv8UZW7JI/G6jD1Z+zAR2QWYYN8KGQ3BM384SizLZFSPuggXAs8z4tbuEaCWvUQapuPqXh8Xvdzt9RwPJ9UkIDbs7V3rE9smli8zUk/NOY6f87Eo5r5bTI4Vdwk+mhcayWSeIOJTNMgnELcE0IfosHsJ9WzgDuPMsiVjGAVCK7hyBg0X9CkLzoNMo3pNof1Zkwr3eSgaNrQFbMT6/2m3AjocYLtSfHJYk55vziIQy2oYFJz6myriwO27XTtCiESSv3ze3t52y4XiS0poAfr5YQq0CSSM36YZhwOU+viH5TchgmG+maM0q982WbIxTbbH8cGMQDcVC5mNequcLlDkb8F7SfAfywQsZz0VZA0FIqtr9QeynZICLK3bSBlDslIjxy9PSuSYlj41jLTdSfhS8+MHHyJNId2lbtVYmuLpHR3zgxEjkgE+gm9IijdXTKFP4A63Qg+uKtcalyVK+VeU+oq1fZlnCbjVSDjac694JqvXwFiMsd9ehQTe4Qjp9gH67i44crk2k/GatYvFKv0rRovYZ9BnH28rO4Bne4VdaQfyhuzNxOxsTBsenfRZwpLch2Ix8L9ftK8uj2IlVJHT5YjtWi3stuL82VB/9E7GdSqxGqeIjbYExdW/POZsn7bFmZQNRtELa/yQfLGO+DJNZrGG43G34BIYyXPUOymeqOmmaw4OhIo3FwNyDMX/VoFiB//gehxkea4EMFfA7qauLvXk+90QBjEHh+meLMj1ZGSiygXBwI0H5uY+C0Vagk+jqz4pHoH6MrtX7qsHerXStso6Iafcrp92eyThumwchrwGtFe/aDJDMXP9nrhFr60jt3+QOZWIgZP9wNmcbzJ1soOYDzM+Y9DQPQ9N+LTxv9MwGhkceasXU25nSAyruJQ//5XLxxswiIbLxFpZS78nMs48VdpB+cAiIUzwfg44P x25kiwq+ yIYjcYjszMqVq/BfXPkEzM7EoKFDWYFgV5MWOGqj3MH7+pPa9wpp0mEQdkxkhgNk55suUNF8a9DpFDAH7LI684mVItZWnor9/mZqo6cPvbPsSLR6OZ42pu1FenJor8/wtiZ3fhKI+uO8ld7fgUjaFOs/W1xR77n3tukybP1OehPgTMYWkqKBiewMsbsnl8Zd/BTf/AXeFeS+99No= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 9/15/2023 10:26 PM, Sean Christopherson wrote: > On Fri, Sep 15, 2023, Yan Zhao wrote: >> On Wed, Sep 13, 2023 at 06:55:16PM -0700, Sean Christopherson wrote: >> .... >>> +static void kvm_mmu_prepare_memory_fault_exit(struct kvm_vcpu *vcpu, >>> + struct kvm_page_fault *fault) >>> +{ >>> + kvm_prepare_memory_fault_exit(vcpu, fault->gfn << PAGE_SHIFT, >>> + PAGE_SIZE, fault->write, fault->exec, >>> + fault->is_private); >>> +} >>> + >>> +static int kvm_faultin_pfn_private(struct kvm_vcpu *vcpu, >>> + struct kvm_page_fault *fault) >>> +{ >>> + int max_order, r; >>> + >>> + if (!kvm_slot_can_be_private(fault->slot)) { >>> + kvm_mmu_prepare_memory_fault_exit(vcpu, fault); >>> + return -EFAULT; >>> + } >>> + >>> + r = kvm_gmem_get_pfn(vcpu->kvm, fault->slot, fault->gfn, &fault->pfn, >>> + &max_order); >>> + if (r) { >>> + kvm_mmu_prepare_memory_fault_exit(vcpu, fault); >>> + return r; >>> + } >>> + >>> + fault->max_level = min(kvm_max_level_for_order(max_order), >>> + fault->max_level); >>> + fault->map_writable = !(fault->slot->flags & KVM_MEM_READONLY); >>> + >>> + return RET_PF_CONTINUE; >>> +} >>> + >>> static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) >>> { >>> struct kvm_memory_slot *slot = fault->slot; >>> @@ -4293,6 +4356,14 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault >>> return RET_PF_EMULATE; >>> } >>> >>> + if (fault->is_private != kvm_mem_is_private(vcpu->kvm, fault->gfn)) { >> In patch 21, >> fault->is_private is set as: >> ".is_private = kvm_mem_is_private(vcpu->kvm, cr2_or_gpa >> PAGE_SHIFT)", >> then, the inequality here means memory attribute has been updated after >> last check. >> So, why an exit to user space for converting is required instead of a mere retry? >> >> Or, is it because how .is_private is assigned in patch 21 is subjected to change >> in future? > This. Retrying on SNP or TDX would hang the guest. I suppose we could special > case VMs where .is_private is derived from the memory attributes, but the > SW_PROTECTED_VM type is primary a development vehicle at this point. I'd like to > have it mimic SNP/TDX as much as possible; performance is a secondary concern. So when .is_private is derived from the memory attributes, and if I didn't miss anything, there is no explicit conversion mechanism introduced yet so far, does it mean for pure sw-protected VM (withouth SNP/TDX), the page fault will be handled according to the memory attributes setup by host/user vmm, no implicit conversion will be triggered, right? > > E.g. userspace needs to be prepared for "spurious" exits due to races on SNP and > TDX, which this can theoretically exercise. Though the window is quite small so > I doubt that'll actually happen in practice; which of course also makes it less > important to retry instead of exiting.