From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.8912.1672992184824086000 for ; Fri, 06 Jan 2023 00:03:05 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=C6z4rIEZ; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1672992183; 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: in-reply-to:in-reply-to:references:references; bh=tOxIyJOnBKcnqFbEmjwn5qZafFvqZ/cxYz1grKuMp0A=; b=C6z4rIEZpyBBs6Qp+IUUoF2Jxvvb5UsLt36FO7Bh3OSnElA1WA8EJUGzRMdQPfJWC/ubXV 34CEGPf1nTPD1uwzZbEOd+W8kHTzx8eLGuODIbHMPaHEhUFDGkdlzEYHB/N3eu+UPSIcQc xtNmc3aPpGZLvaxo2FKM8Orc/qZsUzc= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-42-o5vWbcClPmOgYZe2I7taIQ-1; Fri, 06 Jan 2023 03:03:02 -0500 X-MC-Unique: o5vWbcClPmOgYZe2I7taIQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 04F433815F60; Fri, 6 Jan 2023 08:03:02 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.238]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BDF101121314; Fri, 6 Jan 2023 08:03:01 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 58CBC1800081; Fri, 6 Jan 2023 09:03:00 +0100 (CET) Date: Fri, 6 Jan 2023 09:03:00 +0100 From: "Gerd Hoffmann" To: Laszlo Ersek Cc: devel@edk2.groups.io, ray.ni@intel.com, "ardb@kernel.org" , "Xie, Yuanhao" , thomas.lendacky@amd.com Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg:Fixed AsmRelocateApLoopStart and ensure allocated memory <4GB Message-ID: <20230106080300.tsohpx24ddxjo5x4@sirius.home.kraxel.org> References: <20230105062108.1796-1-yuanhao.xie@intel.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 06, 2023 at 07:42:20AM +0100, Laszlo Ersek wrote: > On 1/6/23 05:12, Ni, Ray wrote: > > > > Ard, > > > > Only AMD X64 (including SEV and without SEV) runs the code that > > switches to 32bit paging disabled mode. > > Intel X64 runs the code that stays at 64bit paging mode. So no need > > for <4G memory. > > All IA32 CPUs (including intel and AMD) stays at 32bit paging disabled > > mode. The AllocateReservedPages() call should not return a memory > > above 4GB in 32bit env. > > This argument about the allocations sounds valid, thanks. > > The code still remains incredibly hard to read. It needs serious > cleanup. > > (1) Wherever we have "Amd" in an identifier, let's rename it to "Amd64", > to better reflect the revised check. Maybe even better: Use PcdConfidentialComputingGuestAttr to figure whenever SEV is active, if so branch into Amd assembler code. Rename "Amd" to "AmdSev". Otherwise just call normal X64 / Ia32 code. Amd assembler code can subsequently be simplified, the checks for SEV are not needed any more (but should not harm either). [ Adding Tom to CC ] > Commit 73ccde8f6d04 ("UefiCpuPkg: Has APs in 64 bit long-mode before > booting to OS.", 2022-12-20) *removed* the executable marking. > > (4a) Is that not a problem? I think so. Booting with strict NX checking (PcdDxeNxMemoryProtectionPolicy = 0xC000000000007FD5) and "qemu -smp 2" makes my qemu hang with 200% CPU, so probably both vcpus are spinning in a dead loop. For the BSP this is expected behavior (buggy grub.efi, see parallel thread). For the AP it is not, so apparently it is not running idle in hlt like it is supposed to. > Honestly, at this point I'm *even more convinced* that the original > series should be reverted, and redone from the ground up. Yes, "back to drawing board" looks like the best option at this point. take care, Gerd