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 019FEECAAD2 for ; Mon, 29 Aug 2022 16:02:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D5A4940008; Mon, 29 Aug 2022 12:02:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 684C0940007; Mon, 29 Aug 2022 12:02:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57513940008; Mon, 29 Aug 2022 12:02:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4845F940007 for ; Mon, 29 Aug 2022 12:02:56 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 20743AB02D for ; Mon, 29 Aug 2022 16:02:56 +0000 (UTC) X-FDA: 79853098752.07.84B63AD Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by imf28.hostedemail.com (Postfix) with ESMTP id CC4F3C001E for ; Mon, 29 Aug 2022 16:02:55 +0000 (UTC) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-3321c2a8d4cso207224357b3.5 for ; Mon, 29 Aug 2022 09:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=8Usi9Hh1KvrJmXEusctcdOFszMM7+qvg9UBwUxClRh0=; b=P63R/tJ1/yc2xe/SYPTrGdLCylhF8Yq/+kzrso3A2VDilTv0adUYIPWvD/PV8NImJF rvP+8ZABp8nUF1fbgcAf4+5O5JPVD7egARXdeRN7M8thmFgzEEcGdam2RaoZaz7SHCPi Ws92dnROdr+EUTrMzw6dPkZFbmHzFWZP6l+r1gQDVO3qkwLPGfevPjuOb+We6iXKTDYl tNpS+apxMlkRoa1XuSVaEByTnXLeRgx4OwVpM1JcBEi/X1wA0qYpX2cVMjcn39Q+NLDe OQeCLFZ+h7GW6hFG2icL9huyDGj4Dzmm6aqgWJYXAz1DCtPWiMwXFxvyVjtCuC4p+lge NjuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=8Usi9Hh1KvrJmXEusctcdOFszMM7+qvg9UBwUxClRh0=; b=wW1/sLRpb4qsONCch1C9KNzFiqYBBBWBP16S/s1Z4QR1mdwYRzQQN/KECBodu/C5bi LKhxyiglMVry6be0yczpkHwxwpdrFvCjXDT53H2f+cWo+bf5u4ygdo6G0qLtwHlT3blc t3VFE93k7ELhypo22ru+CpQj8cIv26lpzcshgB6IFjUltiVPrnpH5VlMhLIgVs2XIckx fRvtCbimxKHFt57YqiPWVIxCn2J455FFU5oj9CUAu+XsDHS65dkyCviR6PDtDaqOpVrX A+OdElmOOgm90zzqzUZvaKMh2JPC0w0q83GVa2NjBuR0rF+1l/6zn3Scuq7Xg6676H+m JSOQ== X-Gm-Message-State: ACgBeo37t+LXuGxJWhe1cpteS9cve/LxmAQry0c/kiMD3Vs3BgY3ubmp wdcq6X3dnu+LHMA4YQy6kO7/2vq+OjupW1TZm9uipg== X-Google-Smtp-Source: AA6agR7/KN4/eHAqKBzu8Y1ODKrUf87PVyGKXZruOIOILGQ04PmnXodL6U9rRi2s20C9/A8QbHpYKGVUuhl+ceHb/GM= X-Received: by 2002:a0d:da41:0:b0:329:91e7:fd06 with SMTP id c62-20020a0dda41000000b0032991e7fd06mr10477748ywe.436.1661788974863; Mon, 29 Aug 2022 09:02:54 -0700 (PDT) MIME-Version: 1.0 References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220614120231.48165-3-kirill.shutemov@linux.intel.com> <8cf143e7-2b62-1a1e-de84-e3dcc6c027a4@suse.cz> <20220810141959.ictqchz7josyd7pt@techsingularity.net> <2981e25e-9cda-518a-9750-b8694f2356b5@amd.com> In-Reply-To: <2981e25e-9cda-518a-9750-b8694f2356b5@amd.com> From: Dionna Amalie Glaze Date: Mon, 29 Aug 2022 09:02:43 -0700 Message-ID: Subject: Re: [PATCHv7 02/14] mm: Add support for unaccepted memory To: Tom Lendacky Cc: Mel Gorman , Vlastimil Babka , "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Dario Faggioli , Dave Hansen , Mike Rapoport , David Hildenbrand , Marcelo Cerri , tim.gardner@canonical.com, Khalid ElMously , philip.cox@canonical.com, "the arch/x86 maintainers" , Linux Memory Management List , linux-coco@lists.linux.dev, linux-efi , LKML , Mike Rapoport Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661788975; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8Usi9Hh1KvrJmXEusctcdOFszMM7+qvg9UBwUxClRh0=; b=yEdh9eelMLPxBTbmY7ayJD31CFJWMFyYg85osPyYDYxehwLd49re+2gdE+0M8ZKCj4Kv0Q z/11CVyFkUXxnqRrwfuz8nvqFtIarKLX9mso5CT131+wD4IuJ7GohIjnos5QxaTJ1XrZvF L2kz9xNeCqnVDUnve0ycUsy03j7q6C4= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="P63R/tJ1"; spf=pass (imf28.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=dionnaglaze@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661788975; a=rsa-sha256; cv=none; b=3Mr3ozymGr+658nUIGQTixAf9TcKDREI6OvnkVoplnj8fWwodpbqUDEdJSWP91lEm0dwJy lEtV5H+EeLcrRxEVJ1ocr0eShsmGCPAmKE+IdRkytxI4n9ykfEcuRTkA/CPlO7jzZxcPKJ nBl95HIP5myXeo+ZNbjnnuCDApFu7Jk= X-Rspam-User: X-Rspamd-Queue-Id: CC4F3C001E X-Stat-Signature: ibijhxqhh5n83ud6xt35tze5aiz6e51q Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="P63R/tJ1"; spf=pass (imf28.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=dionnaglaze@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam08 X-HE-Tag: 1661788975-411817 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: > > The stack track is in mm/page_alloc.c. I've done a little > > investigation, but I can't account for why there's a hard cutoff of > > correctness at 256GB > > > > [ 0.065563] RIP: 0010:memmap_init_range+0x108/0x173 > > [ 0.066309] Code: 77 16 f6 42 10 02 74 10 48 03 42 08 48 c1 e8 0c > > 48 89 c3 e9 3a ff ff ff 48 89 df 48 c1 e7 06 48 03 3d d9 a2 66 ff 48 > > 8d 47 08 47 34 01 00 00 00 48 c7 47 38 00 00 00 00 c7 47 30 ff ff > > ff ff > > [ 0.069108] RSP: 0000:ffffffffad603dc8 EFLAGS: 00010082 ORIG_RAX: > > 0000000000000404 > > [ 0.070193] RAX: ffffdba740000048 RBX: 0000000000000001 RCX: 0000000000000000 > > [ 0.071170] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffdba740000040 > > [ 0.072224] RBP: 0000000000000000 R08: 0000000000001000 R09: 0000000000000000 > > [ 0.073283] R10: 0000000000000001 R11: ffffffffad645c60 R12: 0000000000000000 > > [ 0.074304] R13: 00000000000000a0 R14: 0000000000000000 R15: 0000000000000000 > > [ 0.075285] FS: 0000000000000000(0000) GS:ffffffffadd6c000(0000) > > knlGS:0000000000000000 > > [ 0.076365] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 0.077194] CR2: ffffdba740000074 CR3: 0008001ee3a0c000 CR4: 00000000000606b0 > > [ 0.078209] Call Trace: > > [ 0.078524] > > [ 0.078887] ? free_area_init+0x5c1/0x66c > > [ 0.079417] ? zone_sizes_init+0x52/0x6c > > [ 0.079934] ? setup_arch+0xa55/0xb6d > > [ 0.080417] ? start_kernel+0x64/0x65a > > [ 0.080897] ? secondary_startup_64_no_verify+0xd6/0xdb > > [ 0.081620] > > Note that there is a bug in Brijesh's version of the patch and it will > almost exclusively use the MSR protocol. Please try the version of the > patch that I recently sent up based on the current unaccepted memory tree > from Kirill. > I've now tested this patch set with Tom's new patch set, and it appears to be that the problem with 256GB is more likely to be due to this unaccepted memory patch set rather than something AMD-specific. Kirill, do you see any problems with 256GB on TDX? It seems there is some unaccepted memory getting touched in memmap_init_range when the VM's memory size is at least 256GB -- -Dionna Glaze, PhD (she/her)