From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D016A22352290 for ; Tue, 27 Feb 2018 09:11:54 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8D7688D6F1; Tue, 27 Feb 2018 17:17:59 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-21.rdu2.redhat.com [10.10.120.21]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5B3622024CA2; Tue, 27 Feb 2018 17:17:58 +0000 (UTC) To: Brijesh Singh , edk2-devel@lists.01.org Cc: Tom Lendacky , Jordan Justen , Ard Biesheuvel , Michael Kinney , Paolo Bonzini References: <20180221165212.6643-1-brijesh.singh@amd.com> <20180221165212.6643-3-brijesh.singh@amd.com> <6a0cd77f-13d8-b8dd-8ad2-931347e72a7c@redhat.com> <8138d8c3-678f-fd42-c663-1ae5c2e539b9@amd.com> From: Laszlo Ersek Message-ID: Date: Tue, 27 Feb 2018 18:17:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8138d8c3-678f-fd42-c663-1ae5c2e539b9@amd.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Tue, 27 Feb 2018 17:17:59 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Tue, 27 Feb 2018 17:17:59 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH 2/2] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Clear C-bit when SEV is active X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 17:11:55 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Brijesh, you provided a lot of information (and it seems like your analysis was advancing in parallel with your email -- I too do that sometimes :) ), so it's not easy for me to write a concise response. * Regarding the C-bit that covers the relocated save state area (esp. considering that the area is not page aligned and/or contains executable code): I think (a) adding any code (under OvmfPkg, or under the core) that sets the C-bit "correctly", and in turn, (b) lacking any code in edk2 that actually *exercises* the "correct" C-bit setting, is counter-productive. Unless the C-bit is actively exercised, we're just adding *dead* code, which is a bad thing -- it's very easy to regress (without anyone noticing), and it leads to developer confusion. On the other hand, I wouldn't want your analysis to be lost (remember: I asked for the explanation because I didn't understand the behavior). So I'm thinking your analysis should be captured in both a commit message, and a large comment *somewhere*. Possibly near the code (wherever it may end up, AmdSevDxe or SmmCpuFeaturesLib) where you manage the C-bit for the *initial* save state map. I mean, wherever you manage the C-bit for the initial save state map (which is required), you can also make a large comment on the *future* location and behavior. IMO it's OK if we don't guarantee the guest with functional access into the relocated save state map -- there is no actual code relying on that! -- as long as we document this gap. Does this suggestion make sense to you? * Regarding mapping all the NonExistent and MMIO GCD entries in the SMM page table as plaintext: I think we should really be on par with AmdSevDxe here. This is code that *will* be exercised, and if we cut corners here, next time we add another MMIO range or device that needs to be accessed from SMM too (for whatever reason), we'll go crazy otherwise. * In general, regarding how and when SmmCpuFeaturesLib APIs are hooked into PiSmmCpuDxeSmm: please ask questions -- and ask them to Mike :) OVMF's instance of this lib class is Paolo's work (thanks again for that!), so I always defer to Mike and Paolo whenever this lib class and instance come up. SmmCpuFeaturesInitializeProcessor() looked suitable to me, for implementing the previous bullet, but it's really just my "shopping" for a good pre-existent hook point. If we need something better, let's discuss it with Mike. I'm sorry if the above is a bit too vague; please post some new patches, even if only RFCs :) Thanks! Laszlo