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.3246.1570692906818161638 for ; Thu, 10 Oct 2019 00:35:06 -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-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 57658306731B; Thu, 10 Oct 2019 07:35:06 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-48.rdu2.redhat.com [10.10.120.48]) by smtp.corp.redhat.com (Postfix) with ESMTP id 81FE75DA8D; Thu, 10 Oct 2019 07:35:05 +0000 (UTC) Subject: Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain - To: Andrew Fish , "Gao, Liming" Cc: "devel@edk2.groups.io" References: <1569570395-11240-1-git-send-email-liming.gao@intel.com> <1569570395-11240-12-git-send-email-liming.gao@intel.com> <4c27bdc4-60b4-26bf-c416-c02b69ef8051@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E5124FA@SHSMSX104.ccr.corp.intel.com> <7fc791fe-9d08-9763-ecc9-529e88b621c6@redhat.com> <767711D5-7C33-4703-8E97-F4F5B5A6BD5F@apple.com> <6f49899d-b5e4-70ad-82e5-08c5a8649ac8@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E514EAB@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: <1e3de9da-1218-588a-4632-0263d6f64de5@redhat.com> Date: Thu, 10 Oct 2019 09:35:04 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Thu, 10 Oct 2019 07:35:06 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Andrew, On 10/09/19 18:22, Andrew Fish wrote: > I thought the thing we were discussing was compiler flags. > Specifically -mno-mmx -mno-sse. It seems to me if OVMF requires > -mno-mmx -mno-sse then it is a bug in the tools_def.txt definition > for those compilers? As far as I can tell -mno-implicit-float should > prevent the optimizer from using floating point. The -mno-mmx > -mno-sse flags most change how floating point code gets compiled [1]. > it looks like -mno-mmx -mno-sse just down grade floating point > instructions that get used. Thus it seems like either we have some > code doing float and that code should set -mno-mmx -mno-sse, or the > -mno-mmx -mno-sse should be set generically. The origin of those build flags in OVMF is commit 4a8266f570ef ("OvmfPkg: Work around issue seen with kvm + grub2 (efi)", 2010-12-31): OvmfPkg: Work around issue seen with kvm + grub2 (efi) When OVMF is run with kvm and grub2 (efi), an exception occurs when mmx/sse registers are accessed. As a work around, this change eliminates firmware usage of these register types. First, only the BaseMemoryLib implementation MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf is used. Second, the GCC compiler is passes the additional '-mno-mmx -mno-sse' parameters. The eternal problem with this kind of workaround is that we never know when it becomes safe to remove. It would be nice to understand the exact details around the problem. Given that the commit is from 2010, I assume the issue is difficult to reproduce with recent components (KVM, grub2). On the other hand, if we just remove the flags (which we should, in a perfect world), someone could report a bug in three months: "my host distro upgraded the OVMF package to the next edk2-stableYYYYMM tag, and now my virtual machine, which runs a distro from 2009, no longer boots". (We've seen similar reports before.) Thanks Laszlo