Date: Fri, 22 Mar 2019 13:25:48 -0700 From: D Scott Phillips <d.scott.phillips@intel.com> To: Rebecca Cran <rebecca@bluestop.org>, Larry Rosenman <ler@lerctr.org> Cc: freebsd-virtualization@freebsd.org, owner-freebsd-virtualization@freebsd.org Subject: Re: Updating uefi-edk2-bhyve Message-ID: <86ftremzar.fsf@intel.com> In-Reply-To: <8c63eb87-e3b8-2365-2eaf-a6e36424407c@bluestop.org> References: <86muln68ld.fsf@intel.com> <1fe3ca3f-be70-99db-e7c0-35c9194c97e4@bluestop.org> <7e84fd01c3f46268c26f9bab8b9fb9bc@lerctr.org> <33fcf111-fe00-4ec7-8a2f-7c53246d756f@Spark> <86k1gqanx8.fsf@intel.com> <8c63eb87-e3b8-2365-2eaf-a6e36424407c@bluestop.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Rebecca Cran <rebecca@bluestop.org> writes:
> On 3/22/19 10:12 AM, D Scott Phillips wrote:
>
> >
> > You're seeing this firmware triple fault in the DEBUG build of this new
> > firmware? It seems to be functioning properly for me. Do you get any
> > serial output before the fault?
>
> I do get quite a bit of output before the fault. I'm running 13-CURRENT=20
> (on an Skylake PC), built today, so there may be some new issues that=20
> aren't in a release.
>
> I'm building OVMF with "build -p OvmfPkg/OvmfPkgX64.dsc -a X64 -b DEBUG=20
> -DDEBUG_ON_SERIAL_PORT=3DTRUE -t GCC5"
>
> root@cube:# bhyve -AHP -s 0:0,hostbridge -s 31:0,lpc -c 4 -m 4G -s=20
> 29,fbuf,tcp=3D0.0.0.0:5900,w=3D800,h=3D600 -l bootrom,OVMF_CODE.fd -l=20
> com1,stdio guest
>
> [..snip..]
>
> Memory Allocation 0x00000004 0x806000 - 0x806FFF
> Memory Allocation 0x00000006 0xBFF7C000 - 0xBFFFFFFF
> Memory Allocation 0x00000004 0x820000 - 0x8FFFFF
> Memory Allocation 0x00000004 0x900000 - 0x13FFFFF
> Old Stack size 32768, New stack size 131072
> Stack Hob: BaseAddress=3D0xBBFBE000 Length=3D0x20000
> Heap Offset =3D 0xBB7CE000 Stack Offset =3D 0xBB7BE000
> TemporaryRamMigration(0x810000, 0xBBFD6000, 0x10000)
> vm exit[0]
> reason=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 VMX
> rip=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 0x0000000000827359
> inst_length=C2=A0=C2=A0=C2=A0=C2=A0 5
> status=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0
> exit_reason=C2=A0=C2=A0=C2=A0=C2=A0 2 (Triple fault)
> qualification=C2=A0=C2=A0=C2=A0 0x0000000000000000
> inst_type=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 0
> inst_error=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 0
> Abort
Hmm, I guess it might be some diference in the code generation between
gcc 4.8 and gcc 5.
> On the build problem side, if I run "build -p OvmfPkg/OvmfPkgX64.dsc -a=20
> X64 -t GCC48 -b RELEASE" then I get an error (that I don't get if I=20
> replace GCC48 with GCC5):
>
> /usr/local/bin/ld: warning: cannot find entry symbol _ModuleEntryPoint;=20
> not setting start address
> /usr/local/bin/ld: warning: cannot find entry symbol _ModuleEntryPoint;=20
> not setting start address
> "objcopy"=20
> /home/bcran/workspace/bhyveedk2/Build/OvmfX64/RELEASE_GCC48/X64/OvmfPkg/A=
mdSevDxe/AmdSevDxe/DEBUG/AmdSevDxe.dll
> "objcopy"=20
> /home/bcran/workspace/bhyveedk2/Build/OvmfX64/RELEASE_GCC48/X64/OvmfPkg/E=
muVariableFvbRuntimeDxe/Fvb/DEBUG/EmuVariableFvbRuntimeDxe.dll
> objcopy: error: the input file=20
> '/home/bcran/workspace/bhyveedk2/Build/OvmfX64/RELEASE_GCC48/X64/OvmfPkg/=
EmuVariableFvbRuntimeDxe/Fvb/DEBUG/EmuVariableFvbRuntimeDxe.dll'=20
> has no sections
> objcopy: error: the input file=20
> '/home/bcran/workspace/bhyveedk2/Build/OvmfX64/RELEASE_GCC48/X64/OvmfPkg/=
AmdSevDxe/AmdSevDxe/DEBUG/AmdSevDxe.dll'=20
> has no sections
> make: *** [GNUmakefile:383:=20
> /home/bcran/workspace/bhyveedk2/Build/OvmfX64/RELEASE_GCC48/X64/OvmfPkg/A=
mdSevDxe/AmdSevDxe/DEBUG/AmdSevDxe.dll]=20
> Error 1
I'm not seeing this problem with the build steps I'm doing, which are
just the ones in the ports patch. Perhaps some system version of one of
the build tools is getting used at some point? I had to mess with
${PATH} to get the build to work right. I'd say look back through the
build log and make sure it's using the expected executables. On my side
I'll run the build through poudriere to make sure it's not working due
to some specific quirk of my system.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86ftremzar.fsf>