Re: [Xen-users] My failures so far. Or qemu-stable or upstream?

[Casey DeLorme <cdelorme@xxxxxxxxx>]

I have only ever used the upstream-qemu to test the performance of generic devices with HVM. ÂI don't have statistics, but I did see a reduction in boot times and IO performance was better for emulated / layered devices such as Network and Disk Drives. ÂHowever, the moment I installed PV on HVM drivers, that difference disappeared.

I am using IOMMU for passing a wireless NIC to a router, and a graphics card to a multimedia HVM. ÂFor that reason I haven't tried building ovmf or using upstream recently.

I think this error is probably the one you should be checking, is there a `--64` flag?

gcc: error: unrecognized command line option â--64â

To my understanding all these BIOS are emulated, pretty sure the host machines BIOS is unrelated.

On Sat, Dec 8, 2012 at 12:33 PM, ShadesOfGrey <shades_of_grey@xxxxxxxxxxxxx> wrote:

On 12/07/2012 11:20 PM, Casey DeLorme wrote:

Xen 4.2 compiled from source should include both traditional and upstream qemu.

Upstream does not have complete passthrough support, if you are doing anything of that nature best to stick to traditional.

The Xen Man Pages have the most up to date configuration:

http://wiki.xen.org/wiki/Xen_4.2_Man_Pages

The flag to set per HVM Configuration is `device_model_version`, its values are "qemu-xen" and "qemu-xen-traditional", the traditional being the default. ÂKey benefits are alternative BIOS, though the UEFI BIOS has to be specified to build when compiling Xen.

IIRC, I tried setting the 'device_model_version' flag to "qemu-dm" and "qemu-xen". In both cases I got the error message I quoted. If "qemu-dm" has been deprecated, the error makes sense. If, for some reason, qemu-upstream didn't get pulled down, the error would also make sense. I didn't try try "qemu-xen-traditional". But that's only because I'm pretty sure that, once the other two values failed, I checked the contents of "/usr/lib/xen-4.2/bin/" and found it had no qemu executables.

Still, my recollection could be wrong. I thought I had documented most the non-trivial errors that I encountered. I have a feeling that I lost some of those I captured after reformatting my Dom0 LV. I was pretty sleep deprived after two marathon session last week. So, if I forget to backup my error logs, I could also be misremembering what the results of changing 'device_model_version' values were.

BTW, are there any significant advantages to using the OVMF UEFI firmware? I thought since my motherboard has an UEFI firmware, having qemu use an UEFI firmware might somehow be advantageous. However, the last time I tried compiling Xen with "--enable-ovmf", make bombed out with the following:

"/usr/bin/gcc" -c -x assembler -imacros /mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/DEBUG/AutoGen.h -m64 --64 -melf_x86_64 -o /mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.obj -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg/Library/BaseUefiCpuLib/X64 -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg/Library/BaseUefiCpuLib -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/DEBUG -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/MdePkg -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/MdePkg/Include -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/MdePkg/Include/X64 -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg -I/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg/Include /mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.iii
gcc: error: unrecognized command line option â--64â
make[7]: Leaving directory `/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib'
gcc: error: unrecognized command line option â-melf_x86_64â
make[7]: *** [/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.obj] Error 1


build.py...
Â: error 7000: Failed to execute command
ÂÂÂÂÂÂÂ make tbuild [/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib]


build.py...
Â: error F002: Failed to build module
ÂÂÂÂÂÂÂ /mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf [X64, GCC44, DEBUG]

- Failed -
Build end time: 04:32:20, Dec.08 2012
Build total time: 00:00:02

make[6]: *** [ovmf.bin] Error 1
make[6]: Leaving directory `/mnt/work/src/xen/xen-unstable.hg/tools/firmware/ovmf-remote'
make[5]: *** [subdir-all-ovmf] Error 2
make[5]: Leaving directory `/mnt/work/src/xen/xen-unstable.hg/tools/firmware'
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory `/mnt/work/src/xen/xen-unstable.hg/tools/firmware'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/mnt/work/src/xen/xen-unstable.hg/tools/firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/mnt/work/src/xen/xen-unstable.hg/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/mnt/work/src/xen/xen-unstable.hg/tools'
make: *** [install-tools] Error 2

I wish I knew enough about gcc to understand the significance of those two 'unrecognized command line options'. From what Kristian Hagsted Rasmussen said in his post here, "How to set GCC version for ovmf compilation", he seems to think the problem is a gcc version mismatch. Unfortunately for him and myself, no response has been forthcoming on this particular issue.

Anyway. if having a UEFI firmware for qemu is no real advantage, I'll just install the alternate build of Xen I did without OVMF enabled.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users