On Fri, Mar 20, 2020 at 12:20 AM Fangrui Song maskray@google.com wrote:
On 2020-03-19, Christian Ehrhardt wrote:
Some hardened gcc v9 compilers (such as the one in Ubuntu) default this option which for seabios leads to emulation errors when running in KVM (does not trigger in TCG) on older intel chips of the Penryn generation (~2006-2008).
Symptom in KVM looks like: KVM internal error. Suberror: 1 emulation failure EAX=00000000 EBX=00000000 ECX=000086d4 EDX=00000000 ESI=00000000 EDI=00000000 EBP=000086d4 ESP=00006d7c EIP=00007acf EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 ffffffff 00809300 CS =f000 000f0000 ffffffff 00809b00 SS =0000 00000000 ffffffff 00809300 DS =0000 00000000 ffffffff 00809300 FS =0000 00000000 ffffffff 00809300 GS =0000 00000000 ffffffff 00809300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 000f6200 00000037 IDT= 00000000 000003ff CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 <f3> 0f 1e fb 66 57 66 56 66 53 66 53 66 89 c7 67 66 89 14 24 66 89 ce 66 e8 15 f8 ff ff 88
URL: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1866870 Signed-off-by: Christian Ehrhardt christian.ehrhardt@canonical.com
Makefile | 1 + 1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile index 5f7d5370..9e8188e5 100644 --- a/Makefile +++ b/Makefile @@ -69,6 +69,7 @@ COMMONCFLAGS += $(call
cc-option,$(CC),-fno-stack-protector,)
COMMONCFLAGS += $(call cc-option,$(CC),-fno-stack-protector-all,) COMMONCFLAGS += $(call cc-option,$(CC),-fstack-check=no,) COMMONCFLAGS += $(call cc-option,$(CC),-Wno-address-of-packed-member,) +COMMONCFLAGS += $(call cc-option,$(CC),-fcf-protection=none,) COMMA := ,
CFLAGS32FLAT := $(COMMONCFLAGS) -DMODE16=0 -DMODESEGMENT=0
If this is related to endbr32/endbr64 interpretation failures, please make it clear in the description.
I didn't know it was related to "endbr32/endbr64 interpretation failures" when I was writing the patch :-) I only learned about that when David commented on the LP bug.
But if that helps I can easily add mentioning that in a v2 ...