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 ...