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 6F9F8C43217 for ; Mon, 28 Nov 2022 09:26:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 033A16B0072; Mon, 28 Nov 2022 04:26:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F25D36B0073; Mon, 28 Nov 2022 04:26:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC7A86B0074; Mon, 28 Nov 2022 04:26:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id CD4366B0072 for ; Mon, 28 Nov 2022 04:26:49 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 85ED8140DCB for ; Mon, 28 Nov 2022 09:26:49 +0000 (UTC) X-FDA: 80182321338.01.9753995 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf14.hostedemail.com (Postfix) with ESMTP id 91135100010 for ; Mon, 28 Nov 2022 09:26:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669627608; 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=klYlT0QKH+4SL9No1+i0WufA2DveKgjOeQpHH/zXAQc=; b=YBDuEdUM6zuAGXtK4gf8IhE/MKSF8VxmyYx3OLG3cncR08b7/gOQS94Xe2Tn+f19U5BF5a Gw62whcYX1xRCH6ete/TtUe6M+zU9RW3YAwohVt3cfx6Qgl9c2lEHfxNCJ4Sde70+bwona ynstIGcsDcDQ713p7/P4pkDzMtA4yps= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-294-0KoTnr_8P9WcvxfzldD-mw-1; Mon, 28 Nov 2022 04:26:41 -0500 X-MC-Unique: 0KoTnr_8P9WcvxfzldD-mw-1 Received: by mail-wr1-f72.google.com with SMTP id m24-20020adfa3d8000000b00242168ce9d1so401503wrb.15 for ; Mon, 28 Nov 2022 01:26:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=klYlT0QKH+4SL9No1+i0WufA2DveKgjOeQpHH/zXAQc=; b=zwJIVCCfuNW6Xbu2RpWP3dmJ3X/5Sz9UvsGLRTfS4a0SfaY/cH6DdGGhUWj5slo1Mc dYzj1yyrWARjomuhuq+wy9iKLfOfQ6twxbHGQIgyAJFx/Zt2CYIbIZqbtUyo2qJu40qK y0GJ6ojjTu+NMZdVFeWrNL7lLCPdlXjSedBdNK4zHcL8uS0o87fX7vNLfJOPrXmMgvwu 2fg4/McqZEseFUjEUQ27f6H1DrpHmfGC9iORGnOdKkMBHEopcqK48BpEz+6tAxDsyAOF Tb7a7CwTd5pxsWV9N681Vo/MGjsGWbQ2zoaSmHqvHUHb34kRrx+iieDphUY/r3+ycl64 4stg== X-Gm-Message-State: ANoB5pnwSVba1/gwu+V6WWkbjfmlyWggTn3t5LLVOz00SK5nYEOfADqW P4pWRz5d2kNgTkWln89nYM49RDZxpLcgVlbIStyCxlqt/0rnnQYA/zh719f9SFiJnBeiO2IN3Ky 4koeBhAJa6AI= X-Received: by 2002:a05:600c:3421:b0:3cf:ac8a:d43e with SMTP id y33-20020a05600c342100b003cfac8ad43emr25478665wmp.65.1669627600131; Mon, 28 Nov 2022 01:26:40 -0800 (PST) X-Google-Smtp-Source: AA0mqf5YnAsVdDSPhUTuDTe1E4NOjJSUbaLCxukiYCM/P5NI3OP5blqbagembcddhMNSo3dpxegf3Q== X-Received: by 2002:a05:600c:3421:b0:3cf:ac8a:d43e with SMTP id y33-20020a05600c342100b003cfac8ad43emr25478652wmp.65.1669627599841; Mon, 28 Nov 2022 01:26:39 -0800 (PST) Received: from ?IPV6:2003:cb:c702:9000:3d6:e434:f8b4:80cf? (p200300cbc702900003d6e434f8b480cf.dip0.t-ipconnect.de. [2003:cb:c702:9000:3d6:e434:f8b4:80cf]) by smtp.gmail.com with ESMTPSA id p1-20020a1c5441000000b003b4cba4ef71sm18157087wmi.41.2022.11.28.01.26.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Nov 2022 01:26:38 -0800 (PST) Message-ID: Date: Mon, 28 Nov 2022 10:26:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH v7 10/20] x86/virt/tdx: Use all system memory when initializing TDX module as TDX memory To: "Huang, Kai" , "Williams, Dan J" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Cc: "Hansen, Dave" , "Luck, Tony" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "kirill.shutemov@linux.intel.com" , "Christopherson,, Sean" , "Chatre, Reinette" , "pbonzini@redhat.com" , "linux-mm@kvack.org" , "Yamahata, Isaku" , "peterz@infradead.org" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "Shahar, Sagi" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" References: <9b545148275b14a8c7edef1157f8ec44dc8116ee.1668988357.git.kai.huang@intel.com> <637ecded7b0f9_160eb329418@dwillia2-xfh.jf.intel.com.notmuch> <8e8f72ad5d7a3d09be32bee54e4ebb9c280610a2.camel@intel.com> <361875cb-e4b3-a46f-b275-6d87a98ce966@redhat.com> <397ebe70bf9cede731f2f8bbd05e0df518fd3a22.camel@intel.com> <49ab9f26-9e23-25ab-71b4-e666c70ff77e@redhat.com> <8300f1098aa8fbfae711313be41ee44cb1203d62.camel@intel.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <8300f1098aa8fbfae711313be41ee44cb1203d62.camel@intel.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669627609; 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=klYlT0QKH+4SL9No1+i0WufA2DveKgjOeQpHH/zXAQc=; b=Aeq26/CZdbMPtvEtFNup37++FNsfdCZSvNooNHfngZOToi3titsirRLloDn10BiXOLIJ+w tGobQ43kL8Y+B3Y2LFN6G3SY/XkQK1N7XY0rVnKDYwWunmRL4aWz70TcThPdmGkGRmKaGQ RJGClwFUyb44xnRnHW6J0GSIWJHgmQM= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YBDuEdUM; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf14.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669627609; a=rsa-sha256; cv=none; b=GKCUbY7eMS/JZmCI1e1W28JXuCM6qmPj1MzxwL67fk3cg6seuZnDUOs6V5ECPdNOSxr8hq TEbJh29e4djr/LMPCDSf9HAxEoog0AV6XU+0UN5QJy0H2rYY6ILR8XhK/QvsKLNUWdHddW q03ElTvnZ8D3P9hjO4SUuFjEaC12YJs= X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YBDuEdUM; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf14.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com X-Stat-Signature: myujtecgc5rtoaoarrxk4ik7gqsu5dxb X-Rspamd-Queue-Id: 91135100010 X-Rspamd-Server: rspam08 X-HE-Tag: 1669627608-185097 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 28.11.22 10:21, Huang, Kai wrote: > On Mon, 2022-11-28 at 09:43 +0100, David Hildenbrand wrote: >> On 28.11.22 09:38, Huang, Kai wrote: >>> On Fri, 2022-11-25 at 10:28 +0100, David Hildenbrand wrote: >>>> On 24.11.22 10:06, Huang, Kai wrote: >>>>> On Wed, 2022-11-23 at 17:50 -0800, Dan Williams wrote: >>>>>>> >>>>>>> @@ -968,6 +969,15 @@ int arch_add_memory(int nid, u64 start, u64 size, >>>>>>>    unsigned long start_pfn = start >> PAGE_SHIFT; >>>>>>>    unsigned long nr_pages = size >> PAGE_SHIFT; >>>>>>> >>>>>>> + /* >>>>>>> + * For now if TDX is enabled, all pages in the page allocator >>>>>>> + * must be TDX memory, which is a fixed set of memory regions >>>>>>> + * that are passed to the TDX module.  Reject the new region >>>>>>> + * if it is not TDX memory to guarantee above is true. >>>>>>> + */ >>>>>>> + if (!tdx_cc_memory_compatible(start_pfn, start_pfn + nr_pages)) >>>>>>> + return -EINVAL; >>>>>> >>>>>> arch_add_memory() does not add memory to the page allocator.  For >>>>>> example, memremap_pages() uses arch_add_memory() and explicitly does not >>>>>> release the memory to the page allocator. >>>>> >>>>> Indeed. Sorry I missed this. >>>>> >>>>>> This check belongs in >>>>>> add_memory_resource() to prevent new memory that violates TDX from being >>>>>> onlined. >>>>> >>>>> This would require adding another 'arch_cc_memory_compatible()' to the common >>>>> add_memory_resource() (I actually long time ago had such patch to work with the >>>>> memremap_pages() you mentioned above). >>>>> >>>>> How about adding a memory_notifier to the TDX code, and reject online of TDX >>>>> incompatible memory (something like below)? The benefit is this is TDX code >>>>> self contained and won't pollute the common mm code: >>>>> >>>>> +static int tdx_memory_notifier(struct notifier_block *nb, >>>>> + unsigned long action, void *v) >>>>> +{ >>>>> + struct memory_notify *mn = v; >>>>> + >>>>> + if (action != MEM_GOING_ONLINE) >>>>> + return NOTIFY_OK; >>>>> + >>>>> + /* >>>>> + * Not all memory is compatible with TDX. Reject >>>>> + * online of any incompatible memory. >>>>> + */ >>>>> + return tdx_cc_memory_compatible(mn->start_pfn, >>>>> + mn->start_pfn + mn->nr_pages) ? NOTIFY_OK : NOTIFY_BAD; >>>>> +} >>>>> + >>>>> +static struct notifier_block tdx_memory_nb = { >>>>> + .notifier_call = tdx_memory_notifier, >>>>> +}; >>>> >>>> With mhp_memmap_on_memory() some memory might already be touched during >>>> add_memory() (because part of the hotplug memory is used for holding the >>>> memmap), not when actually onlining memory. So in that case, this would >>>> be too late. >>> >>> Hi David, >>> >>> Thanks for the review! >>> >>> Right. The memmap pages are added to the zone before online_pages(), but IIUC >>> those memmap pages will never be free pages thus won't be allocated by the page >>> allocator, correct? Therefore in practice there won't be problem even they are >>> not TDX compatible memory. >> >> But that memory will be read/written. Isn't that an issue, for example, >> if memory doesn't get accepted etc? >> > > Sorry I don't quite understand "if memory doesn't get accepted" mean. Do you > mean accepted by the TDX module? > > Only the host kernel will read/write those memmap pages. The TDX module won't > (as they won't be allocated to be used as TDX guest memory or TDX module > metadata). So it's fine. Oh, so we're not also considering hotplugging memory to a TDX VM that might not be backed by TDX. Got it. So what you want to prevent is getting !TDX memory exposed to the buddy such that it won't accidentally get allocated for a TDX guest, correct? In that case, memory notifiers would indeed be fine. Thanks! -- Thanks, David / dhildenb