[SeaBIOS] Re: [PATCH v2] build: use -fcf-protection=none when available
On Fri, Mar 20, 2020 at 9:38 AM 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). Hi, other than the request to add "endbr32/endbr64 interpretation failures" to the commit message there was no other feedback. This was done in v2 and since then nothing happened, therefore I wanted to ping if this can be accepted into master? > The symptom appears as endbr32/endbr64 interpretation failures > and in KVM it looks like: > KVM internal error. Suberror: 1 > emulation failure > EAX= EBX= ECX=86d4 EDX= > ESI= EDI= EBP=86d4 ESP=6d7c > EIP=7acf EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ES = 00809300 > CS =f000 000f 00809b00 > SS = 00809300 > DS = 00809300 > FS = 00809300 > GS = 00809300 > LDT= 8200 > TR = 8b00 > GDT= 000f6200 0037 > IDT= 03ff > CR0=0010 CR2= CR3= CR4= > DR0= DR1= > DR2= DR3= > DR6=0ff0 DR7=0400 > EFER= > Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 >00 e9 61 f2 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 > --- > 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 > -- > 2.25.1 > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH v2] build: use -fcf-protection=none when available
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). The symptom appears as endbr32/endbr64 interpretation failures and in KVM it looks like: KVM internal error. Suberror: 1 emulation failure EAX= EBX= ECX=86d4 EDX= ESI= EDI= EBP=86d4 ESP=6d7c EIP=7acf EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 00809300 CS =f000 000f 00809b00 SS = 00809300 DS = 00809300 FS = 00809300 GS = 00809300 LDT= 8200 TR = 8b00 GDT= 000f6200 0037 IDT= 03ff CR0=0010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 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 --- 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 -- 2.25.1 ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] build: use -fcf-protection=none when available
On Fri, Mar 20, 2020 at 12:20 AM Fangrui Song 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= EBX= ECX=86d4 EDX= > > ESI= EDI= EBP=86d4 ESP=6d7c > > EIP=7acf EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 > > ES = 00809300 > > CS =f000 000f 00809b00 > > SS = 00809300 > > DS = 00809300 > > FS = 00809300 > > GS = 00809300 > > LDT= 8200 > > TR = 8b00 > > GDT= 000f6200 0037 > > IDT= 03ff > > CR0=0010 CR2= CR3= CR4= > > DR0= DR1= > > DR2= DR3= > > DR6=0ff0 DR7=0400 > > EFER= > > Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 > > 00 e9 61 f2 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 > >--- > > 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 ... -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH] build: use -fcf-protection=none when available
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= EBX= ECX=86d4 EDX= ESI= EDI= EBP=86d4 ESP=6d7c EIP=7acf EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 00809300 CS =f000 000f 00809b00 SS = 00809300 DS = 00809300 FS = 00809300 GS = 00809300 LDT= 8200 TR = 8b00 GDT= 000f6200 0037 IDT= 03ff CR0=0010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 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 --- 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 -- 2.25.1 ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
Re: [SeaBIOS] 1TB Guest changes to receive phys bits >=40
Thanks, that means it is just as I expected and I only needed the eye opener where to look at. Thanks Paolo and Gerd! On Mon, Jun 11, 2018 at 3:53 PM, Paolo Bonzini wrote: > On 11/06/2018 15:21, Christian Ehrhardt wrote: > > Hi, > > I was asked about x86 Guests of >1TB in size. And while some discussions > > where around qemu/libvirt and host-phys-bits [1] I realized that in > > Seabios I need exactly what is already in CentOS/RHEL [2] to get the > > phys-bits passed on. > > > > The change [2] itself is rather old, so I wondered if I'm missing that > > this was implemented in a totally different way. Do I have to switch/set > > options these days instead of using that patch? > > That patch is not needed anymore. It is only there to support old > machine types. In newer versions of QEMU, QEMU builds the e820 memory > map for SeaBIOS, and that is enough to support >=1TB guests nicely. > > Paolo > > > But I saw that it is still applied even to rather recent versions. > > > > So the question become why the change is not upstream yet? > > Was it maybe discussed in the past and Nack'ed for some reason? > > I didn't find the discussion if that is the case and would appreciate > > the pointer. > > > > We are closing in to make 1TB more common rather quickly, so I wonder if > > really nothing would speak against it - would it be reasonable to > > consider committing that upstream to Seabios these days? > > > > [1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1769053 > > [2]: https://git.centos.org/blob/rpms!seabios.git/ > 14f0fd75785bc5f1468fa84fbd3a1627f3433032/SOURCES!0002-allow- > 1TB-of-RAM.patch > > > > P.S. Subscribing people acking the original patch as they might have old > > context to provide on this. > > > > -- > > Christian Ehrhardt > > Software Engineer, Ubuntu Server > > Canonical Ltd > > -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd ___ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
[SeaBIOS] 1TB Guest changes to receive phys bits >=40
Hi, I was asked about x86 Guests of >1TB in size. And while some discussions where around qemu/libvirt and host-phys-bits [1] I realized that in Seabios I need exactly what is already in CentOS/RHEL [2] to get the phys-bits passed on. The change [2] itself is rather old, so I wondered if I'm missing that this was implemented in a totally different way. Do I have to switch/set options these days instead of using that patch? But I saw that it is still applied even to rather recent versions. So the question become why the change is not upstream yet? Was it maybe discussed in the past and Nack'ed for some reason? I didn't find the discussion if that is the case and would appreciate the pointer. We are closing in to make 1TB more common rather quickly, so I wonder if really nothing would speak against it - would it be reasonable to consider committing that upstream to Seabios these days? [1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1769053 [2]: https://git.centos.org/blob/rpms!seabios.git/14f0fd75785bc5f1468fa84fbd3a1627f3433032/SOURCES!0002-allow-1TB-of-RAM.patch P.S. Subscribing people acking the original patch as they might have old context to provide on this. -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd ___ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
