From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by mx.groups.io with SMTP id smtpd.web12.3099.1571058667389639777
 for <devel@edk2.groups.io>;
 Mon, 14 Oct 2019 06:11:07 -0700
Authentication-Results: mx.groups.io;
 dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.redhat.com (Postfix) with ESMTPS id BE8ED3090FC3;
	Mon, 14 Oct 2019 13:11:06 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-254.ams2.redhat.com [10.36.117.254])
	by smtp.corp.redhat.com (Postfix) with ESMTP id 78FCD60C18;
	Mon, 14 Oct 2019 13:11:00 +0000 (UTC)
Subject: Re: [edk2-devel] [RFC PATCH v2 38/44] UefiCpuPkg: Allow AP booting under SEV-ES
To: Andrew Fish <afish@apple.com>, devel@edk2.groups.io
Cc: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
 Jordan Justen <jordan.l.justen@intel.com>,
 Ard Biesheuvel <ard.biesheuvel@linaro.org>,
 Mike Kinney <michael.d.kinney@intel.com>, Liming Gao <liming.gao@intel.com>,
 Eric Dong <eric.dong@intel.com>, Ray Ni <ray.ni@intel.com>,
 "Singh, Brijesh" <brijesh.singh@amd.com>,
 =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= <philmd@redhat.com>
References: <cover.1568922728.git.thomas.lendacky@amd.com>
 <81e310d1f2929f839cd166d1c7de6694220743b6.1568922729.git.thomas.lendacky@amd.com>
 <284e15f0-25ee-bb69-dcd1-09e146346c69@redhat.com>
 <ee2eefb3-d67f-d9f0-b533-fdcdd2484e9e@redhat.com>
 <f666920b-483b-9a5a-2a28-11415c5fe080@amd.com>
 <d533b2e9-1b0c-ec2c-d628-80dc4628761d@redhat.com>
 <8a8f839a-9e50-29da-06f7-50e3fc3b93c1@redhat.com>
 <851cc695-8902-3b07-4867-a101e0f9ee4f@amd.com>
 <8eb55d97-0ba3-c217-a160-c24730b9f036@amd.com>
 <f0709dcc-cee4-a2c8-d831-6e18aedc601f@redhat.com>
 <635C113A-D0A2-4A11-AF9A-8A65BBE1C9BC@apple.com>
From: "Laszlo Ersek" <lersek@redhat.com>
Message-ID: <8aff5d64-1281-e36e-50b7-096c5dc0da05@redhat.com>
Date: Mon, 14 Oct 2019 15:11:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <635C113A-D0A2-4A11-AF9A-8A65BBE1C9BC@apple.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Mon, 14 Oct 2019 13:11:06 +0000 (UTC)
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 10/12/19 08:42, Andrew Fish wrote:
> Laszlo,
>
> For 2) this  is very unfortunate. I think the root cause is for those
> of us who work on x86 hardware day to day we get programed that
> SEC/PEI is IA32 and DXE is X64, and this can lead to some unfortunate
> coding outcomes.

First I was confused by this; I didn't understand why the "bitness" of
SEC/PEI mattered here.

But, of course, you are right: if SEC/PEI are 32-bit, then the
problematic relocations are never generated by the compiler in the first
place.

> I'm guessing this code probably got ported from the DXE CPU driver or
> some other place that had no XIP assumptions. One option vs. patching
> is putting the relocations in the .data section. The only issue with
> that could be the need to align sections on page boundaries and that
> may take up too much space in XIP code. Perhaps we could only require
> the .data section relocations for XCODE, and map them to .text for
> the other toolchain?

In SEC, all sections of the binary are located in flash, aren't they?
Why would it help if the relocations were placed in .data? I'm reminded
of global variables in SEC, and those are not writable in SEC either.
(At least on QEMU.) I'm uncertain if this is somehow connected to
Cache-as-RAM, but if it is: QEMU does not support Cache-as-RAM.

Thanks
Laszlo