Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp1757219rwb; Fri, 12 Aug 2022 06:27:18 -0700 (PDT) X-Google-Smtp-Source: AA6agR6upBH5v9tGefbVbE3jJCcS4pyh9uaUi/alFPgXiq6GUDuDFw4BX9PcbfE3JMp3YvciRz84 X-Received: by 2002:a17:907:6da8:b0:730:8ed5:2df8 with SMTP id sb40-20020a1709076da800b007308ed52df8mr2693625ejc.75.1660310837930; Fri, 12 Aug 2022 06:27:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660310837; cv=none; d=google.com; s=arc-20160816; b=y+z6sszKnGJsGJEtqffGijDh6J5U/nYdApmTtaj7X2Kkg7yEN7wMq2h9dR/kKwPCug 79Gk2AbtthKUnQfM53agXAKq9hdfBUPiPZ1aqxH3/0zU99Nil1po+pbuncVuVNqbcGHT DQy9hu1atbprKqVkE3PF8rzURKw27JyWwtj82B5sNvZ/XQBK6rIXwRH6kKjjuB+6b2gS GdZCImKNNO7pKl/Vm23B+B0rlWN6HzEygb9FxQEaXS7a3sIbYb3f83aCuPyRc1GRTN+j Mc53edPlQ7OM+yj8sHYN65yfwZLM938kMOMXHGyPUefRHsf+OryLm6/iWcthJQAuLUt8 M+QQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=rxVLkbvNBovfojpBImP7y+g3dx0vMBlRsKjLna4naQc=; b=bHRaDLKLsp7FJQf4euLsB1Kml8XQ1xBL0wu2kY+hAcmAbi9uZLuzOpzVlkiyV4HjH8 HK6DRKYujIoZ7LrV+0k3pQiJkt9c0slJKIc8066sgAVBiv9XbbD2bAsbiXdV96rFZqhJ TeXLMUE728pTGCM0J6Ntv9Npe5Pl2fB6NcwlCXRtBRaEWKQ6x8I6n+fLWG/fzVxT36Hq WyBkyiwGP3hWMhMVgO4RRZ0PB+iczkyG8NdbUtBa17CnLJuW9AwuSKS9F81yGxsyHhFh wMHlPbh6rm8kuXchKTyJJNUlx9oKibABIUvOpP/05oeHgz4D2JMuD+pe8bk9MiS1gMAF wY8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=YB48Q+9P; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cw18-20020a170906479200b007316ac034acsi1923150ejc.834.2022.08.12.06.26.51; Fri, 12 Aug 2022 06:27:17 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=YB48Q+9P; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238877AbiHLNEA (ORCPT + 99 others); Fri, 12 Aug 2022 09:04:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50844 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237763AbiHLNDm (ORCPT ); Fri, 12 Aug 2022 09:03:42 -0400 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83F4124BC2 for ; Fri, 12 Aug 2022 06:03:38 -0700 (PDT) Received: from zn.tnic (p200300ea971b98b3329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:971b:98b3:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 0B4AF1EC054C; Fri, 12 Aug 2022 15:03:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1660309413; 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:in-reply-to:in-reply-to: references:references; bh=rxVLkbvNBovfojpBImP7y+g3dx0vMBlRsKjLna4naQc=; b=YB48Q+9PKC7TayFIL/Rda/07y5czDrfWi0t1pm0NuddPJBaykm0wpz63l6N3+ATOxCDk9X iaE9a6hFhNnH7Jd93pl26FKUzEyddFL+h09JG0kENcigpkx3xFLjA+j9G7wTM3kt1tHJef 7oAIsQgumVOcOuq1TdDKDbIiupBhD7c= Date: Fri, 12 Aug 2022 15:03:28 +0200 From: Borislav Petkov To: Tom Lendacky Cc: linux-kernel@vger.kernel.org, x86@kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen , "Kirill A. Shutemov" , "H. Peter Anvin" , Michael Roth , Joerg Roedel , Andy Lutomirski , Peter Zijlstra Subject: Re: [PATCH v2 1/2] x86/sev: Put PSC struct on the stack in prep for unaccepted memory support Message-ID: References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <21d5d55640ee1c5d66501b9398858b6a6bd6546f.1659978985.git.thomas.lendacky@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <21d5d55640ee1c5d66501b9398858b6a6bd6546f.1659978985.git.thomas.lendacky@amd.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,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: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 08, 2022 at 12:16:24PM -0500, Tom Lendacky wrote: > In advance of providing support for unaccepted memory, switch from using > kmalloc() for allocating the Page State Change (PSC) structure to using a > local variable that lives on the stack. This is needed to avoid a possible > recursive call into set_pages_state() if the kmalloc() call requires > (more) memory to be accepted, which would result in a hang. I don't understand: kmalloc() allocates memory which is unaccepted? > The current size of the PSC struct is 2,032 bytes. To make the struct more > stack friendly, reduce the number of PSC entries from 253 down to 64, > resulting in a size of 520 bytes. This is a nice compromise on struct size > and total PSC requests. Why can't you simply allocate that one PSC page once at boot, accept the memory for it and use it throughout? Under locking, ofc, if multiple PSC calls need to happen in parallel... Instead of limiting the PSC req size. > @@ -1254,6 +1260,8 @@ void setup_ghcb(void) > if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP)) > snp_register_per_cpu_ghcb(); > > + ghcb_percpu_ready = true; You know how I can't stand those random boolean vars stating something has been initialized? Can't you at least use some field in struct ghcb.reserved_1[] or so which the spec can provide to OS use so that FW doesn't touch it? And then stick a "percpu_ready" bit there. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette