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 C50C1C433EF for ; Mon, 18 Apr 2022 20:22:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 357298D001F; Mon, 18 Apr 2022 16:22:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DD6B8D001A; Mon, 18 Apr 2022 16:22:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 109B08D001F; Mon, 18 Apr 2022 16:22:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id ED81F8D001A for ; Mon, 18 Apr 2022 16:22:57 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id CAC3381EC1 for ; Mon, 18 Apr 2022 20:22:57 +0000 (UTC) X-FDA: 79371123594.22.227E04B Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf11.hostedemail.com (Postfix) with ESMTP id 48D984000C for ; Mon, 18 Apr 2022 20:22:57 +0000 (UTC) Received: by mail-lf1-f44.google.com with SMTP id x33so25954945lfu.1 for ; Mon, 18 Apr 2022 13:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mLWlEzJdMk6tuaRzUj9I+DP1OAyBtJ6ETvbVsO93HOU=; b=yZIHcmsAVppuK5qGX6G7Ih1KsaYwCGYPWcLwUZ27iXpxzXC8ZDAaHgGx5sYhn9MaCP xmLMaguzDZIuQDxf+3nkkYN3A5yqEEx48BjaZ0e6az1nMfgAklIa3Os763c4R+X+N6el QaYjjkSK2R8mjyRoG2lpWhBp5IOolBIOsRov4CLNh+OfkZDYKvgvTneU6MFu+rau3Wk5 bkLeeQKm54yRp+3IuYfgQdJwuNhEovhToYoM9FNb4pNcSLZ+NSYUtbPsqQS1mvxdlUPN 2InIBy8S//cm7hYkWhSU5Hk0FsYBts2vpIF6rafJ0L7gGOIfM+MEvGH3gfvM57loO7W9 SFwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mLWlEzJdMk6tuaRzUj9I+DP1OAyBtJ6ETvbVsO93HOU=; b=aCYV//Uhhyel6tL1Byi448iuJEvlJZr2lJZSqzn1hW4qdL6wSudGeHoWo0CfwUgj1J lpL7bY6A+9EcItib/Mqv8S8c0JdVC7q0FAI+rXkGUcjoJgj1ibrgy69A0KBlCnCcDR+l wId7dronP5kAdq8UAP5stdJz8dfCSCeOLLOQ6zUa4wLc40KJ5+bOqnHWKlbzv5I53NBI vQvMi2ZP2+sprYBPaGc6lDLpohbX4rn1v7vFk9S7sz5zaXqtAFI0dPcf4tfIqJHL84bN hG61jp463hyC14iGiH/GzOWW3i/XODgUYLpT7mhH7usk3JlkSF9lZLYlW1kymq6sq85e JgaQ== X-Gm-Message-State: AOAM533A2oMz8LTZ9Vc7m62mcyUXnJhPlFsd070e4WrOl/2R1OG5Zz+J aHFeveA/nwVBajt75inoSz57UQ== X-Google-Smtp-Source: ABdhPJznQzqX7bRzuIcLKDjKwu+NX1wiOv40zQz/yldUBixOb1SSMsMrFJrGumBZeV0L5NkatxL6aw== X-Received: by 2002:a05:6512:ac9:b0:470:e6d0:1bd8 with SMTP id n9-20020a0565120ac900b00470e6d01bd8mr7300071lfu.614.1650313375515; Mon, 18 Apr 2022 13:22:55 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id z1-20020a0565120c0100b00447a7c10e4dsm1313059lfu.31.2022.04.18.13.22.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Apr 2022 13:22:54 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 64BF5103A61; Mon, 18 Apr 2022 23:24:31 +0300 (+03) Date: Mon, 18 Apr 2022 23:24:31 +0300 From: "Kirill A. Shutemov" To: Borislav Petkov Cc: "Kirill A. Shutemov" , 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 , Dave Hansen , Brijesh Singh , Mike Rapoport , David Hildenbrand , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv4 3/8] efi/x86: Implement support for unaccepted memory Message-ID: <20220418202431.whvql4w57c7l5vpw@box.shutemov.name> References: <20220405234343.74045-1-kirill.shutemov@linux.intel.com> <20220405234343.74045-4-kirill.shutemov@linux.intel.com> <20220418155545.a567xnxa6elglapl@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 48D984000C X-Rspam-User: Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=yZIHcmsA; dmarc=none; spf=none (imf11.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.167.44) smtp.mailfrom=kirill@shutemov.name X-Stat-Signature: 1cgqhyn5mwmxmweh7snycoy5yo8zicz8 X-HE-Tag: 1650313377-801491 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 Mon, Apr 18, 2022 at 06:38:52PM +0200, Borislav Petkov wrote: > > Could you explain what rules are? > > Library-like stuff like types.h, linkage.h, etc we could include for now > but including linux/kernel.h which pulls in everything but the kitchen > sink is bad. doesn't include or similar things. Is it okay for now? > > Hm. accept_or_mark_unaccepted()? > > What's wrong with early_accept_memory()? But the goal of the function is not to accept the memory, but mark it as unaccepted in the bitmap. Your proposal is more confusing, not less. > > > Immediately? As opposed to delayed? > > > > Yes. Otherwise accept is delayed until the first allocation of the memory. > > Yes, put that in the comment pls. Okay. > memory, but it is not > > 1:1 match. Unaccepted memory can be present without memory ecnryption if > > data secruty and integrity guaranteed by other means. > > Really? > > Please elaborate. I thought memory acceptance is a feature solely for > TDX and SNP guests to use. Conceptionally, it is just memory that requires additional action before it can be accessed. Yes, at the moment TDX and SEV are the only users. It is implementation detail that TDX and SEV use memory encryption. > > is very AMD SME/SEV centric. > > So? > > > I'm not sure it need to exist in the way it is now. > > I'm not sure what your argument actually is for having yet another > separate header vs putting it in a header which already deals with that > stuff. Because I don't think it is a good fit. Frankly, even fits better, although I'm no a fan either. Do we have file shortage? I would rather keep it separate. > > Okay, I will move it into a separate function, but it has to be called > > from allocate_e820() because it allocates and free the map. > > You mean, you want for allocate_e820() to call this new function because > both allocate and free? > > Might have to explain what you mean here exactly. Both allocate_e820() and handling unaccepted memory requires access to the efi memory map. We only need the size of memory map for e820, while unaccepted memory requires walking the map. We can serve both by requesting the map from the firmware once. It requires allocation and freeing memory for the map. Makes sense? -- Kirill A. Shutemov