From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (NAM01-BN3-obe.outbound.protection.outlook.com [40.107.74.51]) by mx.groups.io with SMTP id smtpd.web09.843.1574440816089178605 for ; Fri, 22 Nov 2019 08:40:16 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@amdcloud.onmicrosoft.com header.s=selector2-amdcloud-onmicrosoft-com header.b=FgfzO6D+; spf=none, err=SPF record not found (domain: amd.com, ip: 40.107.74.51, mailfrom: thomas.lendacky@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JF/SLLBlGmgoCM+C9M5jrP7oVXj2wbUSZzuRGPWmkcN8L1dTyzKTondmOUeOwlxi95izTMUbpLqkfwESuVW+QtaV302KwTAbj3Kca54m3gcxIQjgqy5RBfHhggmoULFDdIoI/hqRZZ7YK5m+LcxNYJG89V2psowzgL3HQtatgsvcN6t4PguKbTQ/TLbVfM0BguSDMcqmNC2+y0sJV6ph80hKc8lBYyjdFZ1kLFn18mbBPBLlkDw/7zlq7ZRFKhx/Bdy+dNHpL4JFabqgS8uYbrwgmEupyui8VzIJHgqQ7uSsWAA+E0x5arsH0M2BCyi8Alqgfyz6r4oQWTaSWi6nSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1+OHfbsIHwFd/VTfcxMOG5Fq1laqcgZ8pOuajoFZplo=; b=hZL6gTRHtUGB5fThOWKbH0boBPZWOAY8wqPhmSmTjWB1O1CFcrowJOLYcYwryPHIHYAHmEZ51YpGPGJotjZLYVuW7Q+d3+AC/unX46GwKj764n6MQe0ufb3+bdKOYRx5+nlSMV0DbFIyXCojXmqYyHQyPWoakUteg9Vl2lcCfD3PMPAIVggCyOiKapTipnGxXntDjK8eEy8oYxDZzVR6AbQayiwvCCgCMcrrGBxpHtrSxJjwdV9+Imeg13QRfiuLNJpU+cCgX1Pvv90fYhf3DfSG/N9metwfHE7RsaurRC06tlYfn6k8YDf+C+5VyDH057JY/8xFzmKGFJXZeF4pTA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amdcloud.onmicrosoft.com; s=selector2-amdcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1+OHfbsIHwFd/VTfcxMOG5Fq1laqcgZ8pOuajoFZplo=; b=FgfzO6D+fOXk7Vb9sJC8sBJq4K0NR+9jFGPiMQY6AkLhw3PBBaIj5m5N0jBUoMOcW5YxotFdFosm3tsD8DdC8FUv7xGXKcrCjzF9hiU/5JTKFU23EAWtph5vKIT7ovqYnHrEwxtTci3IU/WF+FbAYP5zP6RDVp3/rVkmPou5eaU= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Lendacky@amd.com; Received: from DM6PR12MB3163.namprd12.prod.outlook.com (20.179.71.154) by DM6PR12MB4234.namprd12.prod.outlook.com (10.141.184.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.21; Fri, 22 Nov 2019 16:40:14 +0000 Received: from DM6PR12MB3163.namprd12.prod.outlook.com ([fe80::dd0c:8e53:4913:8ef4]) by DM6PR12MB3163.namprd12.prod.outlook.com ([fe80::dd0c:8e53:4913:8ef4%5]) with mapi id 15.20.2474.019; Fri, 22 Nov 2019 16:40:14 +0000 Subject: Re: [edk2-devel] [RFC PATCH v3 37/43] OvmfPkg: Reserve a page in memory for the SEV-ES AP reset vector To: Laszlo Ersek , devel@edk2.groups.io Cc: Jordan Justen , Ard Biesheuvel , Michael D Kinney , Liming Gao , Eric Dong , Ray Ni , Brijesh Singh References: <706f17aa0ea3ed3f57c1e933e93164a94ba1a0cf.1574280425.git.thomas.lendacky@amd.com> <85a5bcf3-25e2-7298-bca6-cef09cdb5d47@redhat.com> From: "Lendacky, Thomas" Message-ID: Date: Fri, 22 Nov 2019 10:40:09 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 In-Reply-To: X-ClientProxiedBy: SN4PR0501CA0035.namprd05.prod.outlook.com (2603:10b6:803:40::48) To DM6PR12MB3163.namprd12.prod.outlook.com (2603:10b6:5:15e::26) Return-Path: thomas.lendacky@amd.com MIME-Version: 1.0 X-Originating-IP: [165.204.84.11] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: e445faed-d046-4cfd-fa62-08d76f6aa63d X-MS-TrafficTypeDiagnostic: DM6PR12MB4234:|DM6PR12MB4234: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 02296943FF X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4636009)(376002)(136003)(396003)(346002)(366004)(39860400002)(189003)(199004)(52116002)(36756003)(2486003)(23676004)(31696002)(76176011)(316002)(58126008)(478600001)(8936002)(47776003)(14454004)(6116002)(3846002)(4326008)(99286004)(81156014)(7736002)(81166006)(229853002)(53546011)(6506007)(65806001)(65956001)(66066001)(25786009)(50466002)(305945005)(86362001)(386003)(6512007)(31686004)(2616005)(446003)(11346002)(6436002)(66476007)(66556008)(8676002)(26005)(6486002)(54906003)(14444005)(186003)(66946007)(2906002)(230700001)(5660300002)(6246003)(6666004);DIR:OUT;SFP:1101;SCL:1;SRVR:DM6PR12MB4234;H:DM6PR12MB3163.namprd12.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; Received-SPF: None (protection.outlook.com: amd.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: =?utf-8?B?RmFGbnFXV3B2Qlo5WGxqSWdXQXdxQndFeFNwMkNWbnRQakh1NyszQWsvQWZU?= =?utf-8?B?enpXNmpHcnlvbWJjZWpDK1g2K2E0Z2djOThLUW1ySTdnSksySno2TFVaZVFC?= =?utf-8?B?YnRGbXJPbVlYNldTNWJuS0h0U2o2NEpKTEZPOW5vTlJzUS9wditvc1JqNVN1?= =?utf-8?B?bWgvREFoWEtsLzJOUVh0WXM3VG5ENndiN3pwbi9PUkJLVTVQWXZIbi9GRGVt?= =?utf-8?B?THI2ZmRYUXVCN1VzZlBvcG01NHNzSnE2UjJ5dEZmV3dtckl5MENWM0swaGNV?= =?utf-8?B?QU5UZ0JReTJLdDBTcFpIRHV6cENhNU1PeVFCeE1HNzY3SjZrZjk2V0F0cWEv?= =?utf-8?B?UFp6T1Nsb0YzVXhQN0RuVzNvYjhEeDc0Tko0VXl4RVNCckYyODVyRFhMUkZK?= =?utf-8?B?eXBLWVFUSXUrWno2T0RDc2ZMMTg0ZGtmeFp1dTl3L3FnMEFuajArRXJkT1ZO?= =?utf-8?B?WmUyczJzMEpYZGxUdFNRaUZLejJHM085WVVFY2UybG1HRG9IYUNDQUpHelcw?= =?utf-8?B?eWRzMDNnNGxkZ0lTOUlKcXBGYm1yRy96bGZDZm83b2cwUGlQUmRyYVJVL3d5?= =?utf-8?B?VjlBRWtHNG9xY3U4ZzVkSVREUUtKN1B2QXJWNjlCMUhrUkhOQ3drNEJEWXJp?= =?utf-8?B?LzA1Tm9uRGFacEszVHFSNlIzNjB4TnQ3VEdyV2UrYUxPTjlvMVdzTUpEVCtw?= =?utf-8?B?emRHemZEMTRmMThsQ09Ua0x2SFFrWW5BTkZKdG5lajExcmhrSnZzaWhCTmU1?= =?utf-8?B?WTZxaDBxYzRJRUNuWXg2TU9pemViNUpCdjhNY3BUU0FGSVFhZTUreEZVMmtS?= =?utf-8?B?MEt2Zm1JeERCTk0wUHdLOG5XdDliM09yam1HbDdoUFB1c3EzQXdhM3AwWCt0?= =?utf-8?B?OWw3cHE4c2NHMmczWDZBUlQwTlNxVmkyR1lpQVB3Ym1IOVZuUzAxWW03M1Jo?= =?utf-8?B?TW5XNDM3YUI1b1RvcmFHS043alJ0ampCNXY1UUszTFZLNG82VjhGTXdTcmth?= =?utf-8?B?dHFtYlBrVVREcjJGNmJCY2JEWE1zaGowVHljZHpNWTVYSjVYbFJWNFhyYVRs?= =?utf-8?B?M1YybFZHMUh1ZG0zaENxNlUvci9yK1ZSckRlUXhzY1FDS0Zjai91d2NHVmhY?= =?utf-8?B?VkFUQ0lZdG1ONGVhbFo3RUJYa0RRdVoxdk42aFhIUTVLSkN5cDZZeGdGTyt3?= =?utf-8?B?NEpVSkt4aTBhR0lYU1JZYVJ0aXpkSFo1cVl3NXk1aU5KWlNxbEQzeGszRllw?= =?utf-8?B?d1BXU1gydzJUckRFQlp4LzBTbkR5R0pKLzhOcTdPbjhZMjBqUm9qRVd1ZldI?= =?utf-8?B?MGZuVXdDY3NUZWZFZDE1ZXVJNkx5QUpVV1BxRUt1a3cyZVpsd3JraThLS2Ra?= =?utf-8?B?MU5CbmNHaitwQlF2RlVucXpNMUpsSXd0NWN6dUpYRDNUUGhUc0NCMGdrYXNR?= =?utf-8?B?SmJwdDc1M0xQbmFUSDVLbWh0YVV6QVRDUWs4OVpubVFIREVxYkhPZVh0N0xo?= =?utf-8?B?elhUL2UxamlPUisxekRmdktjU2NlbS83UjBobTVoSE1aRkYrTjcvZmdDdTQw?= =?utf-8?B?WmhFQmdFZi9VM0pBV09VZXphUWlCYlR4SE1la0tORUxVaEFxSmZ2YjBoM3po?= =?utf-8?B?L1hRdGtWM0hNMFloZDhSQllCeWVvKzgyZ2w4TDBrNVBDK3l6RFZhMkVDaVJV?= =?utf-8?B?Vit2UVdkTktSeEdjSnhGdlBwM1Z6MVZZVG5USkxRRU5aOGFHTzdGS0Ivazdt?= =?utf-8?B?dHZMVDBEZVlJclJXcC9kVThxMTdpRGV6MVBsNW03Q25UbTYrbzdBdndMUHg3?= =?utf-8?B?OGh5K1ZNc1hybDRQWWxvTmNaN3NCeFFYbVhKdjdCbHdRTk5xSUhtSXJ1M3Rl?= =?utf-8?B?OVU4MFRoYlpORlVhTnZSWUdDbEpFWWlLRE5GY1FzM0xYTWJteWdBS0VmWXRD?= =?utf-8?B?QytGNVFWZWh3NlFRTzhnaGlsR0tyWFdLQmJRNjV3N2lPMlc4dW52NHdwZEdh?= =?utf-8?B?WUtxMnBUNExNOEsvTkVOd1htKzNINE1yRGgzWjV3TXdUUkVta3dMZFFRZ1Qz?= =?utf-8?B?MDgrbTBEYkpDM0pkMmFHQTgxK203dU1iY2gwQlY2UFBxWnFFbldhV2VHT0Zp?= =?utf-8?B?WWNZdnRQYlluTjdjR1BacXRkYTFHbGdwM1I1ZU9WelJVUmJCK0ZrUm5acVBR?= =?utf-8?B?M2NxMWpXZkpnSEQvckdkVDhKWnpCUHkyMW55NDRNTlNtUXBtZ0VSVlRFTEhE?= =?utf-8?B?SW9qb2NQOGo5V2M5bTJodWhhUCs4aGcraVI0ZklBL2dLd1ZnWTV3emlKRktz?= =?utf-8?B?MFRRY2JrNkU0NGo2WTVuYlB1UTEwRzYyeXlnMjFXcGpmNHhVN1JBc1IvMmFN?= =?utf-8?B?T1lVaW8rcE9FaWRYS1g5ZkU4NG5IN3RMaExEbHowRk8vRFlRRkRGMW9Gd3VD?= =?utf-8?B?UzE5c29GY3c1OTZmbGc9PQ==?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: e445faed-d046-4cfd-fa62-08d76f6aa63d X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2019 16:40:14.5588 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vY2HT7LoYPTx9cLXAEK8IVPHNC+kx4RPZFWZnZ6HAcVftLgsr4RmPNbxjaITyIpSmsZB+01jQS1o267i3IkSLw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4234 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/22/19 10:06 AM, Laszlo Ersek wrote: > On 11/21/19 23:49, Tom Lendacky wrote: >> On 11/21/19 1:27 PM, Laszlo Ersek wrote: >>> On 11/20/19 21:06, Lendacky, Thomas wrote: > >>>> +; sevEsResetBlock: >>>> +; For the initial boot of an AP under SEV-ES, the "reset" RIP must be >>>> +; programmed to the RAM area defined by SEV_ES_RESET_IP. A known offset >>>> +; and GUID will be used to locate this block in the firmware and extract >>>> +; the build time RIP value. The GUID must always be 48 bytes from the >>>> +; end of the firmware. >>>> +; >>>> +; 0xffffffca (-0x36) - IP value >>>> +; 0xffffffcc (-0x34) - CS selector value >>> >>> (5) I think the documentation of these four bytes is incorrect. >>> (Similarly in the previous patch, in the commit message.) We populate >>> these bytes with the *linear address* of the "reset trampoline" where >>> the host will have to boot the AP for the first time. It's not >>> expressed in real mode CS:IP notation / meaning. >> >> This is correct. The code will be in "big real mode" as you note below >> (the reset vector is actually 0xfffffff0, just below 4GB and running >> in 16-bit mode). >> >> If you look in Qemu, target/i386/cpu.c, x86_cpu_reset(), you'll see >> where the CS segment is being loaded with a base of 0xffff0000 and the >> eip gets loaded with 0xfff0. > > That still doesn't explain the above field names to me ("IP value" and > "CS selector value"). Once the firmware image is built, we have: > > - CS: 0x0080 > - IP: 0xB000 > > I don't understand the CS=0x80 part as > - either a genuine segment selector > - or the linear segment base address 0x800 (formed per real-address > mode). > >> So the change to Qemu takes the "CS selector value" and effectively >> left shifts it 16-bits to set the base > > This logic seems correct, as it translates 0x80 to 0x80_0000, i.e. 8 MB. > > However, I still think it's wrong to call the 16-bit value 0x0080 that > we store at 0xffff_ffcc a "CS selector value". It is not a CS selector > value, because it neither points into a segment descriptor table, nor is > it left-shifted by 4-bits to form a linear base address, as in > real-address mode. > > I would call this field > > most significant 16 bits of the CS base address [1] > >> and sets the eip to the "IP value" (in actuality, Qemu reads this as a >> 32-bit value starting at the IP value and ANDs it with 0xffff0000 to >> get the base and 0x0000ffff to get the eip. > > That seems correct to me. > > So... to summarize my point (5), *all* I'm asking for is to change the > field description from "CS selector value" to [1] (or something to the > same effect). > >> >>> >>> >>> (6) Which brings me to my main point... Value 0x00B000 (for the >>> "base" PCD) is relative to the base address of FD.MEMFD, namely 8MB >>> (see MEMFD_BASE_ADDRESS). >>> >>> IOW, the ultimate value of SEV_ES_RESET_IP will be 0x0x0080_B000. >>> That address is larger than 1MB. >> >> Which is ok since Qemu will set up CS appropriately. >> >>> >>> Therefore, the host will have to launch the AP (for the first time) >>> above 1MB (in guest-phys address space). >> >> Which is also OK, just like the BSP was launched at 0xFFFF_FFF0. >> >>> >>> How can that work, if the AP is supposed to start in real mode? The >>> linear address 0x0x0080_B000 cannot be expressed in 16-bit real mode >>> CS:IP notation at all. >>> >>> Does the hypervisor start the AP in "big real mode" (16-bit mode with >>> 4GB segment limits, and CS containing a segment selector, not the >>> actual segment base)? > > Actually, I have to retract my question (6), because here I got lost in > the weeds. I keep forgetting the following quirk in the Intel SDM: > > 9.1.4 First Instruction Executed > > The first instruction that is fetched and executed following a > hardware reset is located at physical address FFFFFFF0H. This > address is 16 bytes below the processors uppermost physical address. > The EPROM containing the software- initialization code must be > located at this address. > > The address FFFFFFF0H is beyond the 1-MByte addressable range of the > processor while in real-address mode. The processor is initialized > to this starting address as follows. The CS register has two parts: > the visible segment selector part and the hidden base address part. > In real-address mode, the base address is normally formed by > shifting the 16-bit segment selector value 4 bits to the left to > produce a 20-bit base address. However, during a hardware reset, the > segment selector in the CS register is loaded with F000H and the > base address is loaded with FFFF0000H. The starting address is thus > formed by adding the base address to the value in the EIP register > (that is, FFFF0000 + FFF0H = FFFFFFF0H). > > The first time the CS register is loaded with a new value after a > hardware reset, the processor will follow the normal rule for > address translation in real-address mode (that is, [CS base address > = CS segment selector * 16]). To insure that the base address in the > CS register remains unchanged until the EPROM based software- > initialization code is completed, the code must not contain a far > jump or far call or allow an interrupt to occur (which would cause > the CS selector value to be changed). > > I need to be reminded of this every once in a while! > > While reviewing your patch, I thought that in real mode, the CS base > address played no part, only the CS selector did -- which would be > left-shifted by 4 bits directly, to form the segment base, in > real-address mode. > > However, the fact is that the CS base address *always* plays a part > (even in real mode). The "left shifting by 4 bits" does not occur when > the CS:IP *reference* is made, but when the CS register is *loaded* > explicitly, in real-address mode. > > And, at reset, CS is *pre-loaded* > - with selector=0xF000, and > - (as a quirk!) with base=0xFFFF_0000 (and *not* with base=0xF_0000, as > the selector would otherwise dictate in real-address mode). > > And the QEMU change is that, at first AP boot, the CS will be pre-loaded > - with selector=0x80 (which is a complete happenstance -- it's > irrelevant!), > - and, importantly, with base=0x80_0000 (and *not* with base=0x800, as > the selector would otherwise dictate in real-address mode). > > So, it's all clear now (as long as you can please confirm that my > understanding is finally correct). > > Thus, question (6) falls away. > >>> ... I guess that would answer my question (6) -- and the last few >>> patches in this series, before this one, *do* suggest "big real mode" >>> to me --, but the documentation around (5), and in the commit message >>> of the previous patch, still doesn't match that. >> >> I'll expand on the commit message to indicate that Qemu, or others, >> must do something similar relative to the CS register setup. > > To summarize, my request would be: > > - in the previous patch, please replace, in the commit message, > > Reset CS > > with > > most significant 16 bits of the reset CS base address > > - in this patch, please replace, in the code comment, > > CS selector value > > with > > most significant 16 bits of the CS base address > > (I mean... you *could* keep the current language in both places, but > then you would have to describe this *entirely new* quirk for forming > the CS base address from the CS selector value. This new SEV-ES / QEMU > method does not match *any* { CS selector --> CS base address } > transformation from the SDM, so you'd have to be quite verbose in the > documenation. > > Given that the CS selector value 0x80 is completely irrelevant here, and > we only care about the ultimate CS base address 0x80_0000, I'd suggest > defining the 16-bit field at 0xffffffcc in terms of the desired CS base > address [1], and not once mentioning "selector".) Let me work on the wording and see what I come up with. I'll pass it by you to see if it makes sense. Thanks, Tom > > Thanks! > Laszlo >