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 BF664C433F5 for ; Wed, 13 Apr 2022 11:32:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1965D6B0072; Wed, 13 Apr 2022 07:32:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1455D6B0073; Wed, 13 Apr 2022 07:32:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F278B6B0074; Wed, 13 Apr 2022 07:32:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0079.hostedemail.com [216.40.44.79]) by kanga.kvack.org (Postfix) with ESMTP id E3E896B0072 for ; Wed, 13 Apr 2022 07:32:26 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9D37FAA09D for ; Wed, 13 Apr 2022 11:32:26 +0000 (UTC) X-FDA: 79351642692.28.2E99C18 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf13.hostedemail.com (Postfix) with ESMTP id 284A42000C for ; Wed, 13 Apr 2022 11:32:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649849545; h=from:from: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; bh=cw+3SgfZDxAhFDomQUYr7roHFhrC3wRHLqsz1pX4r4U=; b=ZONQ+fl4TgyeXnI3KWBUrxGjhAem7g/aPmUqHGswnah1K3fiq4q+vF6vyhPQjyyFJTEvDS U8Dvx3tom4Mtyu+VCW2gbxtkhsRopjMQksx6QaPveX8i9kOcU6KdFLN5j0HuIMccs802o8 yNdOaBc8uMM6N2kotvhnAoypew9WK1A= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-221-lqP7ePjEP4i_JiY42xJ9Ig-1; Wed, 13 Apr 2022 07:32:24 -0400 X-MC-Unique: lqP7ePjEP4i_JiY42xJ9Ig-1 Received: by mail-wm1-f72.google.com with SMTP id g9-20020a1c4e09000000b0038f20d94f01so482777wmh.8 for ; Wed, 13 Apr 2022 04:32:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=cw+3SgfZDxAhFDomQUYr7roHFhrC3wRHLqsz1pX4r4U=; b=3r9JRq3QkN95OjdZxt77N+N/SMMgnbxE6WB2MxNx47BFAG37i9Nohz/yrxb5u2FBDy E1HE5Tc+zxQSe9kFlE/b8djqnBwnPpiTpOSAclI7HPS69ctI6LeoS1KlrkLuTJEwf4EG 34LD0qvJiJIiyQ+vcd6IMWP3dfY6MX+c2e1BqXHo39mEXXIHtSrRC0J2X9KWNsYkSh6X UN6aBr70Vls3qGAAnax6MwDvep+BNQfDhHVVxLSi+uPzhssdnRXB5hqmvFLWVnG969OX 95hNFH4NrQBoF+oEijwiysFTpukc/ZaTzCJ12qZR2sM0q6lRDQ6YJGrglSGybHYNKSyx 8IhQ== X-Gm-Message-State: AOAM533ruoBXy77fvQEOzok5x5XmRT2lvfubnX21cjwj5h3yURg/aoie Gos4FTvK791txD8M4jvr2Eemh+Wd1HtPiPNjUu0f4TRXuePw7tBTF68ulSo5sx92g2WgbzkLowl s4q/04v8++X0= X-Received: by 2002:adf:dd10:0:b0:207:a8ce:c152 with SMTP id a16-20020adfdd10000000b00207a8cec152mr9888730wrm.714.1649849543301; Wed, 13 Apr 2022 04:32:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwpw+J1XKXzR0hCFUlh7TDtDEB5sanD73+NCToQFB1rqBDGGXxpw/7OeMjq4vgU34cwcTjz7Q== X-Received: by 2002:adf:dd10:0:b0:207:a8ce:c152 with SMTP id a16-20020adfdd10000000b00207a8cec152mr9888690wrm.714.1649849543000; Wed, 13 Apr 2022 04:32:23 -0700 (PDT) Received: from ?IPV6:2003:cb:c704:5800:1078:ebb9:e2c3:ea8c? (p200300cbc70458001078ebb9e2c3ea8c.dip0.t-ipconnect.de. [2003:cb:c704:5800:1078:ebb9:e2c3:ea8c]) by smtp.gmail.com with ESMTPSA id p125-20020a1c2983000000b0038e6c62f527sm2554558wmp.14.2022.04.13.04.32.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Apr 2022 04:32:22 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2022 13:32:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCHv4 1/8] mm: Add support for unaccepted memory To: "Kirill A. Shutemov" Cc: Dave Hansen , "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Brijesh Singh , Mike Rapoport , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Mike Rapoport References: <20220405234343.74045-1-kirill.shutemov@linux.intel.com> <20220405234343.74045-2-kirill.shutemov@linux.intel.com> <93a7cfdf-02e6-6880-c563-76b01c9f41f5@intel.com> <20220413113024.ycvocn6ynerl3b7m@box.shutemov.name> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20220413113024.ycvocn6ynerl3b7m@box.shutemov.name> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: u56ynxh7zm5ryahjtmpouhs73ey9tyzb Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ZONQ+fl4; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf13.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-Rspamd-Queue-Id: 284A42000C X-HE-Tag: 1649849545-375664 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 13.04.22 13:30, Kirill A. Shutemov wrote: > On Wed, Apr 13, 2022 at 12:36:11PM +0200, David Hildenbrand wrote: >> On 12.04.22 18:08, Dave Hansen wrote: >>> On 4/12/22 01:15, David Hildenbrand wrote: >>>> Can we simply automate this using a kthread or smth like that, which >>>> just traverses the free page lists and accepts pages (similar, but >>>> different to free page reporting)? >>> >>> That's definitely doable. >>> >>> The downside is that this will force premature consumption of physical >>> memory resources that the guest may never use. That's a particular >>> problem on TDX systems since there is no way for a VMM to reclaim guest >>> memory short of killing the guest. >> >> IIRC, the hypervisor will usually effectively populate all guest RAM >> either way right now. > > No, it is not usual. By default QEMU/KVM uses anonymous mapping and > fault-in memory on demand. > > Yes, there's an option to pre-populate guest memory, but it is not the > default. Let me be clearer: I'm talking about the TDX/SEV world, not ordinary unencrypted VMs. For ordinary encrypted VMs we do have populate on demand frequently. For SEV we currently pin all guest memory and consequently don't have populate on demand. For TDX, again, I did not follow how fd-based private guest memory will behave. I thought I remembered that we will similarly not have populate-on-demand. Preallocation is usually used with huge pages, but I guess that's out of scope right now for encrypted VMs. -- Thanks, David / dhildenb