From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web10.10310.1677159181894290875 for ; Thu, 23 Feb 2023 05:33:02 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=AUZkpx5i; spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 137B9B8191D for ; Thu, 23 Feb 2023 13:33:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B61F0C4339B for ; Thu, 23 Feb 2023 13:32:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677159178; bh=jnQPJMunSL4l+RFgEKfiyWnYFxOpB/J54LYdBrFOOYI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=AUZkpx5in39Itfg4QuixoEJdbPklaFpqbXIWm1Tdo717ezandyvB9Fm2dY/8MYP35 vn/x6qACX0duO6KS3/V4ShvKStQ+S1yDeaHuS00Iz1k6eDFdgkc5ZiZVOJYs5UUe32 s9sCCzVNuC/CycBxKfE+xLuCNW8rwih9C7mfIvYayNtgFCNuEMSUwyYBZI0py+zdfX fZYrMOhe6cQery5t/oKyKjLkIAZoatJbQSBYgdrCNwiwJ/SSbzI/U5q+hoOUUM+JOj AXgbjnFA6fkusYuZqcevj/bMhRNVzl0hwAEm2Dw+TeQAQhCGIc9zD0rGz8xKWIGYnq BumC6r7Vln8EQ== Received: by mail-lj1-f172.google.com with SMTP id z42so3109358ljq.13 for ; Thu, 23 Feb 2023 05:32:58 -0800 (PST) X-Gm-Message-State: AO0yUKWk6OMAQmyQmUTESsEXYWhKTW0R7cIaBGHsq3MWQW4sJ2UsV2tf jmYGQRdoOxBnAzsPi1ZXMEig4sWGHnG6pQ0M9Y4= X-Google-Smtp-Source: AK7set+o5Mpc//Z7ar2wqIKJKYYQshErFgswo4bfYUE49F6rJHzAtR+SiHv6EhmuRvMjqmTh8wgPR+4G8OzKZFoRGc4= X-Received: by 2002:a2e:aa1c:0:b0:293:4ed3:a404 with SMTP id bf28-20020a2eaa1c000000b002934ed3a404mr3641142ljb.2.1677159176740; Thu, 23 Feb 2023 05:32:56 -0800 (PST) MIME-Version: 1.0 References: <20230220052022.9290-1-yuanhao.xie@intel.com> <20230220052022.9290-3-yuanhao.xie@intel.com> <20230221092615.rc3h2hpucmgbou6d@sirius.home.kraxel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Thu, 23 Feb 2023 14:32:45 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [Patch V2 2/5] UefiCpuPkg: Contiguous memory allocation and code clean-up. To: devel@edk2.groups.io, yuanhao.xie@intel.com Cc: Gerd Hoffmann , "Dong, Guo" , "Ni, Ray" , "Rhodes, Sean" , "Lu, James" , "Guo, Gua" Content-Type: text/plain; charset="UTF-8" On Thu, 23 Feb 2023 at 06:53, Yuanhao Xie wrote: > > Hi, > > Set "Address = BASE_4GB - 1" first is to ensure the maximum address value is 4GB, since APs will be switched to 32 bit before OS, I mean in the original implementation. > By the way, in patch 5, only SEV-ES processor keep this limitation, since for the generic processors they keep in 64 bit before handing off the process to OS, and for those 32-bit processors, they don't need this limitation. > > Regards, > Yuanhao > -----Original Message----- > From: Gerd Hoffmann > Sent: Tuesday, February 21, 2023 5:26 PM > To: devel@edk2.groups.io; Xie, Yuanhao > Cc: Dong, Guo ; Ni, Ray ; Rhodes, Sean ; Lu, James ; Guo, Gua > Subject: Re: [edk2-devel] [Patch V2 2/5] UefiCpuPkg: Contiguous memory allocation and code clean-up. > > Hi, > > > + Address = BASE_4GB - 1; > > Why do you set Address here ... > > > + Status = gBS->AllocatePages ( > > + AllocateMaxAddress, > > + EfiReservedMemoryType, > > + StackPages+FuncPages, > > + &Address > > + ); > > ... when it is overridden here anyway? > AllocateMaxAddress uses the provided address as the upper bound for the allocation.