Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ec935cfd-17fc-a6b6-b424-2e514512f94d@amd.com>
Date:   Fri, 12 Aug 2022 08:52:08 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH v7 00/14] KVM: mm: fd-based approach for supporting KVM
 guest private memory
Content-Language: en-US
To:     Chao Peng <chao.p.peng@linux.intel.com>,
        Sean Christopherson <seanjc@google.com>
Cc:     Sean Christopherson <seanjc@google.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
        Hugh Dickins <hughd@google.com>,
        Jeff Layton <jlayton@kernel.org>,
        "J . Bruce Fields" <bfields@fieldses.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Shuah Khan <shuah@kernel.org>, Mike Rapoport <rppt@kernel.org>,
        Steven Price <steven.price@arm.com>,
        "Maciej S . Szmigiero" <mail@maciej.szmigiero.name>,
        Vlastimil Babka <vbabka@suse.cz>,
        Vishal Annapurve <vannapurve@google.com>,
        Yu Zhang <yu.c.zhang@linux.intel.com>,
        "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
        luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com,
        ak@linux.intel.com, david@redhat.com, aarcange@redhat.com,
        ddutile@redhat.com, dhildenb@redhat.com,
        Quentin Perret <qperret@google.com>,
        Michael Roth <michael.roth@amd.com>, mhocko@suse.com,
        Muchun Song <songmuchun@bytedance.com>, bharata@amd.com,
        kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
        linux-api@vger.kernel.org, linux-doc@vger.kernel.org,
        qemu-devel@nongnu.org, linux-fsdevel@vger.kernel.org,
        "Gupta, Pankaj" <pankaj.gupta@amd.com>
References: <20220706082016.2603916-1-chao.p.peng@linux.intel.com>
 <b21f41e5-0322-bbfb-b9c2-db102488592d@amd.com>
 <9e86daea-5619-a216-fe02-0562cf14c501@amd.com>
 <20220811133255.GB916119@chaop.bj.intel.com>
From:   "Nikunj A. Dadhania" <nikunj@amd.com>
In-Reply-To: <20220811133255.GB916119@chaop.bj.intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R09oVmI5WjBvQTU1WUs1akhSR1lwR3o0cVlMOHRqcmYyQnFYMXFwbG5ZSFov?=
 =?utf-8?B?N3E0UUI2cFdVSnhXZFB5TmNjSUxKUnZrcW8zcTZNZXg4Wi8vR1NESXJJVDlW?=
 =?utf-8?B?WnBIRGx3d0VPaU9YVzlsb3dnWThRQkJ3aE9GUzVWMzVNdFVQSjZPQTZsTEto?=
 =?utf-8?B?WHh5OUEwcE43NU5rRmF6Y29HY1l0OUM1M2VMZTlFSUcvTTZ5d1B1eTRMdm1s?=
 =?utf-8?B?cHN0Q0tUWmUzNmFaZ1RiNHA2VGUrVDQ3KzgrZi9HSmZLWUczWFpxQVJ6VGps?=
 =?utf-8?B?a0lVQmQ5WXRxR0YvVnhka3hJWlFUUjMyaTRXc1lLN3BPN3VNbkRabmJLcFRz?=
 =?utf-8?B?WGtVb1V3bEJydFRKVnRQZDVWS2dpR2NJaVdObDVxbGd4cHRlZ01DaDNOaFhJ?=
 =?utf-8?B?MURudFpoSmFOVVMrTElpVS8wYWZldCtLTGg3eElLRjFMTzZtVFIvKzlhY0xp?=
 =?utf-8?B?eWY3dll6Q05rb2VORlhCV1BvUWdSYjl6NDVNRDd0c2dJOWpESU5aaStNUzhy?=
 =?utf-8?B?a0F6WW5Gc1haUTM0MFc5QmVkQzBCcVRkZjFvK05ja1Vvdm1OOWl6TEdqZ1NO?=
 =?utf-8?B?ZW5ZZXptSjZkRVE2OXN6VTZ4NCtmdVhtQi94WWYxTTdmNGJFb3FSZmtPTXlm?=
 =?utf-8?B?TmpMVUxtZFZ5YkYvU2h5ell6eHFVRGxtdXhqYk1xcncyelYrbEQ1QVAyWXo5?=
 =?utf-8?B?Y3RxdHdXK3k2dGZyK0RXZnN5UXkwNDVWRHI1Yjc1aklHOEZrWkR6UWdWZlhj?=
 =?utf-8?B?dmlrTkNqazhsQStaa3dmYm40cnZtZk5CaHFMVDJDVi9TejBxOHZxak1UenRS?=
 =?utf-8?B?aWt4cndmYzBiMEFtdGx4QW9RZWlKNFFWQzQyWGZEMFJqdHJVK1M0c3ZEQXZH?=
 =?utf-8?B?M2Zzb1o2ZER0b053VTRtVjRheDc5WVhEYUR5WVUxaWlMVk9QUjNCeGtmTjRY?=
 =?utf-8?B?NXVFdGM1QXpyS0VQTVk2K2k3YTNkVjJpNlRJT1p1V0RBNGZGZGNKS2RVdVYv?=
 =?utf-8?B?eGp5aUVCZ1JxU2QwZ3RDTjFDTjZJQVUrZHJNVHVNZjV1c3hJWW5CU0hxMUt5?=
 =?utf-8?B?NUluMUthV21VN0ZRdHkwbVJCRjg5VDJvVVgrdDV6dFZYaGpnV3hKOFNlektx?=
 =?utf-8?B?bFU4UWo0NTcwUW1yL3h3RDVZUHRSc1dUbEtGQmVKck54U01pYXBRU1lxWFBu?=
 =?utf-8?B?MW1MbGduQjEveU9yTVRMTHYwZWRkRmZDV21nN1JjaFBhS1VCdjRBZks3NFEx?=
 =?utf-8?B?c21mSlcwMDhuUXVKeXFxU1JBTXQyTVRVNmg5RDQ3aU9hK0o5SFhlY08vOHox?=
 =?utf-8?B?NVZqUjdmT0UxSUc4aUZNYlMwMkdadkFIZzIzaTB4cm5Tc1ZmbGxpUzVVVWFF?=
 =?utf-8?B?S1BKVVcvZ1ZKQ3NMSzJGRnVSaVBpRXpNV1hNNlRkTW1jVElPcWIrSmtvZWto?=
 =?utf-8?B?dXJabENxdm40TGdaTWZaYzh4cE9sUFRwaHRtMTA5WDlWeTRYbUVxdFpTRDdJ?=
 =?utf-8?B?YzBjbGNYQ1hJNWJPQjNNSStLSlRvZXJRZ0h4OHV2M2I0OURVZ3hFN0g3ZVhN?=
 =?utf-8?B?Q0I3dk91L00xbEt2ZkRKeWU1ZGN4cjQ3dWRGbnRid2pmYmJ5bU9LUjM4R3R0?=
 =?utf-8?B?MmZIR1ZYT09UMDg2QzFnRkpWUTh0b0FIR3FvSUpKOWttK096U2xTUXBZNjAy?=
 =?utf-8?B?aVoxZVlsM1ZyQ0VCT2djS2YvQzI2c3RZckgvVFc5VU9Mc0N0S3dNdytGa05E?=
 =?utf-8?B?cWh0NzUrbXJMdWk3elVUdHFIUUtiWmpjYlo5L3VmUk04WUM0S3BFVXQ5UHA5?=
 =?utf-8?B?cElVUWt4SkZBOGdIUE1HcnBHb3l6TUFqWkk5SzVDN2tEemJ5Y2h3NFp5cUw4?=
 =?utf-8?B?QStwR3FKc2ZnNkUxZTlZeTJoUDhMdm1LRzJ6K0ZNa1JwUytvZ2dkSzdQUWFP?=
 =?utf-8?B?TlZVbjdSMHc5Wjc4azN4WXZtWG1YMk1nN0VUeGUvNTcvOWU1UkpocElaazV5?=
 =?utf-8?B?OXVremdkSnFHZ1BFMDBmN2doVWdRQzJ3UkdqaFRIeS9qNzhGSHBEcVlNbnk5?=
 =?utf-8?B?K0FNek4wRDNJMnRTRGlmMTZVU0JKdWxDcUdiNVEwM2dhTkZwK2hkYWdKcmlH?=
 =?utf-8?Q?hDcEgvbihpvbTFe0co91eb8P3?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 921e126d-cff8-47af-a560-08da7c11e4ed
X-MS-Exchange-CrossTenant-AuthSource: DS7PR12MB6309.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Aug 2022 03:22:32.7957
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: xZgy0f3LWs2S3phIjAbmAyA/aG8MjzTXJ/opErAzSgjLGdspJZfvMnkowIANHqn6dR/pwHHJFKRyoBFsdX7vVQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5818
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 11/08/22 19:02, Chao Peng wrote:
> On Thu, Aug 11, 2022 at 01:30:06PM +0200, Gupta, Pankaj wrote:
>>>
>>> While debugging an issue with SEV+UPM, found that fallocate() returns
>>> an error in QEMU which is not handled (EINTR). With the below handling
>>> of EINTR subsequent fallocate() succeeds:
> 
> QEMU code has not well-tested so it's not strange you met problem. But
> from the man page, there is signal was caught for EINTR, do you know
> the signal number?
> 
> Thanks for you patch but before we change it in QEMU I want to make sure
> it's indeed a QEMU issue (e.g. not a kernel isssue).
> 
>>>
>>>
>>> diff --git a/backends/hostmem-memfd-private.c b/backends/hostmem-memfd-private.c
>>> index af8fb0c957..e8597ed28d 100644
>>> --- a/backends/hostmem-memfd-private.c
>>> +++ b/backends/hostmem-memfd-private.c
>>> @@ -39,7 +39,7 @@ priv_memfd_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>>>       MachineState *machine = MACHINE(qdev_get_machine());
>>>       uint32_t ram_flags;
>>>       char *name;
>>> -    int fd, priv_fd;
>>> +    int fd, priv_fd, ret;
>>>       if (!backend->size) {
>>>           error_setg(errp, "can't create backend with size 0");
>>> @@ -65,7 +65,15 @@ priv_memfd_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
>>>                                      backend->size, ram_flags, fd, 0, errp);
>>>       g_free(name);
>>> -    fallocate(priv_fd, 0, 0, backend->size);
>>> +again:
>>> +    ret = fallocate(priv_fd, 0, 0, backend->size);
>>> +    if (ret) {
>>> +           perror("Fallocate failed: \n");
>>> +           if (errno == EINTR)
>>> +                   goto again;
>>> +           else
>>> +                   exit(1);
>>> +    }
>>>
>>> However, fallocate() preallocates full guest memory before starting the guest.
>>> With this behaviour guest memory is *not* demand pinned. 

This is with reference to the SEV demand pinning patches that I was working on. 
The understanding was UPM will not reserve memory for SEV/TDX guest in the beginning 
similar to normal guest. Here is the relevant quote from the discussion with Sean[1]:

	"I think we should abandon this approach in favor of committing all our resources
	to fd-based private memory[*], which (if done right) will provide on-demand pinning
	for "free". "

>>> Is there a way to prevent fallocate() from reserving full guest memory?
Regards
Nikunj
[1] https://lore.kernel.org/kvm/YkIh8zM7XfhsFN8L@google.com/