* [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary? @ 2016-02-04 22:06 Alex Braunegg 2016-02-04 22:22 ` Andrew Cooper 0 siblings, 1 reply; 8+ messages in thread From: Alex Braunegg @ 2016-02-04 22:06 UTC (permalink / raw) To: xen-devel Hi all, Following on from Steven's question (http://lists.xen.org/archives/html/xen-devel/2016-02/msg00801.html) - I have a question around xl's usage of the 'qemu-system-i386' binary When I was testing the changes required for enabling websockets, I was testing qemu by itself (to validate that vnc & websockets were working through qemu) by using the a command similar to the following: /usr/lib/xen/bin/qemu-system-i386 -boot d -cdrom /storage0/data-shares/iso/CentOS-6.5-x86_64-minimal.iso -vnc :1,websocket,x509=/etc/pki/xen In this case, proceeding past the 'Install' selection of the ISO Grub menu always resulted in the following error: This kernel requires an x86_64 CPU but only detected an i686 CPU Unable to boot - please use a kernel appropriate for your CPU I get this and understand why - I invoked qemu using 'qemu-system-i386' which is emulating an i386 / i686 system. This is where things get interesting - consider the following HVM configuration (test2.cfg): ------------------------------------------ builder='hvm' memory = 512 shadow_memory = 8 uuid = '4789b84d-3cdd-409f-9899-88bb13652176' name = 'test2' vif = [ 'bridge=br0, mac=00:16:3e:f1:48:8c' ] disk = [ '/dev/zvol/storage0/xen/test2/disk_sda,,hda','/storage0/data-shares/iso/Cent OS-6.5-x86_64-minimal.iso,,hdc,cdrom' ] boot='cd' sdl=0 vnc=1 vncconsole=1 vnclisten='0.0.0.0' stdvga=1 serial='pty' usbdevice='tablet' vncpasswd='12fDKOkCEZ' vncdisplay=0 localtime=1 audio='1' soundhw='ac97' ------------------------------------------ When the configuration file is used via 'xl': xl create /etc/xen/config/test2.cfg The virtual machine starts without issue, there is no problem installing the system, there is no OS warning about the CPU type. Looking at the ps output: ------------------------------------------ root 30511 46.4 0.1 398728 1860 ? RLsl 08:47 0:27 /usr/lib/xen/bin/qemu-system-i386 -xen-domid 6 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-6,server,n owait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-6,server,nowait -mon chardev=libxenstat-cmd,mode=control -nodefaults -name test2 -vnc 0.0.0.0:0,websocket,x509=/etc/pki/xen,password,to=99 -display none -serial pty -device VGA,vgamem_mb=16 -boot order=cd -usb -usbdevice tablet -soundhw ac97 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:f1:48:8c -netdev type=tap,id=net0,ifname=vif6.0-emu,script=no,downscript=no -machine xenfv -m 496 -drive file=/dev/zvol/stor age0/xen/test2/disk_sda,if=ide,index=0,media=disk,format=raw,cache=writeback -drive file=/storage0/data-shares/iso/CentOS-6.5-x86_64-minimal.iso,if=ide,index=2, readonly=on,media=c drom,format=raw,cache=writeback,id=ide-5632 ------------------------------------------ So - to me it appears that xl is performing some sort of x86_64 -> i386/i686 instruction translation to make things work. Would this not be introducing a performance impediment by having some sort of extra translation processing going on between xl and the qemu binary? Best regards, Alex ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary? 2016-02-04 22:06 [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary? Alex Braunegg @ 2016-02-04 22:22 ` Andrew Cooper 2016-02-04 23:14 ` Steven Haigh 2016-02-04 23:44 ` Alex Braunegg 0 siblings, 2 replies; 8+ messages in thread From: Andrew Cooper @ 2016-02-04 22:22 UTC (permalink / raw) To: Alex Braunegg, xen-devel On 04/02/2016 22:06, Alex Braunegg wrote: > root 30511 46.4 0.1 398728 1860 ? RLsl 08:47 0:27 > /usr/lib/xen/bin/qemu-system-i386 -xen-domid 6 -chardev > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-6,server,n > owait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev > socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-6,server,nowait > -mon chardev=libxenstat-cmd,mode=control > -nodefaults -name test2 -vnc > 0.0.0.0:0,websocket,x509=/etc/pki/xen,password,to=99 -display none -serial > pty -device VGA,vgamem_mb=16 -boot order=cd -usb -usbdevice tablet -soundhw > ac97 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:f1:48:8c -netdev > type=tap,id=net0,ifname=vif6.0-emu,script=no,downscript=no -machine xenfv -m > 496 -drive file=/dev/zvol/stor > age0/xen/test2/disk_sda,if=ide,index=0,media=disk,format=raw,cache=writeback > -drive > file=/storage0/data-shares/iso/CentOS-6.5-x86_64-minimal.iso,if=ide,index=2, > readonly=on,media=c > drom,format=raw,cache=writeback,id=ide-5632 > > ------------------------------------------ > > So - to me it appears that xl is performing some sort of x86_64 -> i386/i686 > instruction translation to make things work. > > Would this not be introducing a performance impediment by having some sort > of extra translation processing going on between xl and the qemu binary? Qemu is only used for device emulation when used with Xen, not CPU emulation. The "-machine xenfv" tells this to Qemu, and "-xen-domid 6" tells it which Xen domain to connect to. All HVM domains run with hardware virtualisation extensions, which are managed by Xen itself. ~Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary? 2016-02-04 22:22 ` Andrew Cooper @ 2016-02-04 23:14 ` Steven Haigh 2016-02-05 0:12 ` Andrew Cooper 2016-02-04 23:44 ` Alex Braunegg 1 sibling, 1 reply; 8+ messages in thread From: Steven Haigh @ 2016-02-04 23:14 UTC (permalink / raw) To: Andrew Cooper; +Cc: Alex Braunegg, xen-devel On 2016-02-05 09:22, Andrew Cooper wrote: > On 04/02/2016 22:06, Alex Braunegg wrote: >> root 30511 46.4 0.1 398728 1860 ? RLsl 08:47 0:27 >> /usr/lib/xen/bin/qemu-system-i386 -xen-domid 6 -chardev >> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-6,server,n >> owait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev >> socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-6,server,nowait >> -mon chardev=libxenstat-cmd,mode=control >> -nodefaults -name test2 -vnc >> 0.0.0.0:0,websocket,x509=/etc/pki/xen,password,to=99 -display none >> -serial >> pty -device VGA,vgamem_mb=16 -boot order=cd -usb -usbdevice tablet >> -soundhw >> ac97 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:f1:48:8c >> -netdev >> type=tap,id=net0,ifname=vif6.0-emu,script=no,downscript=no -machine >> xenfv -m >> 496 -drive file=/dev/zvol/stor >> age0/xen/test2/disk_sda,if=ide,index=0,media=disk,format=raw,cache=writeback >> -drive >> file=/storage0/data-shares/iso/CentOS-6.5-x86_64-minimal.iso,if=ide,index=2, >> readonly=on,media=c >> drom,format=raw,cache=writeback,id=ide-5632 >> >> ------------------------------------------ >> >> So - to me it appears that xl is performing some sort of x86_64 -> >> i386/i686 >> instruction translation to make things work. >> >> Would this not be introducing a performance impediment by having some >> sort >> of extra translation processing going on between xl and the qemu >> binary? > > Qemu is only used for device emulation when used with Xen, not CPU > emulation. > > The "-machine xenfv" tells this to Qemu, and "-xen-domid 6" tells it > which Xen domain to connect to. > > All HVM domains run with hardware virtualisation extensions, which are > managed by Xen itself. Hi Andrew, Thanks for this response - to ensure I have this correct, there is no need for qemu-upstream to build qemu-system-x86_64 as the CPU is directly handled by Xen and not by qemu - thereby passing through the capabilities of the CPU directly to the guest. As such, as long as qemu starts on a 64 bit machine it will be able to run 64 bit OS/kernel etc. I ask this as I see a number of qemu packages that do include qemu-system-x86_64 as well as qemu-system-i386 - which makes me seek clarification. I would assume that these are just not built to use Xen as the hypervisor for hardware acceleration? -- Steven Haigh Email: netwiz@crc.id.au Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary? 2016-02-04 23:14 ` Steven Haigh @ 2016-02-05 0:12 ` Andrew Cooper 2016-02-05 9:56 ` Ian Campbell 0 siblings, 1 reply; 8+ messages in thread From: Andrew Cooper @ 2016-02-05 0:12 UTC (permalink / raw) To: Steven Haigh; +Cc: Alex Braunegg, xen-devel On 04/02/2016 23:14, Steven Haigh wrote: > On 2016-02-05 09:22, Andrew Cooper wrote: >> On 04/02/2016 22:06, Alex Braunegg wrote: >>> root 30511 46.4 0.1 398728 1860 ? RLsl 08:47 0:27 >>> /usr/lib/xen/bin/qemu-system-i386 -xen-domid 6 -chardev >>> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-6,server,n >>> owait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev >>> socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-6,server,nowait >>> >>> -mon chardev=libxenstat-cmd,mode=control >>> -nodefaults -name test2 -vnc >>> 0.0.0.0:0,websocket,x509=/etc/pki/xen,password,to=99 -display none >>> -serial >>> pty -device VGA,vgamem_mb=16 -boot order=cd -usb -usbdevice tablet >>> -soundhw >>> ac97 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:f1:48:8c -netdev >>> type=tap,id=net0,ifname=vif6.0-emu,script=no,downscript=no -machine >>> xenfv -m >>> 496 -drive file=/dev/zvol/stor >>> age0/xen/test2/disk_sda,if=ide,index=0,media=disk,format=raw,cache=writeback >>> >>> -drive >>> file=/storage0/data-shares/iso/CentOS-6.5-x86_64-minimal.iso,if=ide,index=2, >>> >>> readonly=on,media=c >>> drom,format=raw,cache=writeback,id=ide-5632 >>> >>> ------------------------------------------ >>> >>> So - to me it appears that xl is performing some sort of x86_64 -> >>> i386/i686 >>> instruction translation to make things work. >>> >>> Would this not be introducing a performance impediment by having >>> some sort >>> of extra translation processing going on between xl and the qemu >>> binary? >> >> Qemu is only used for device emulation when used with Xen, not CPU >> emulation. >> >> The "-machine xenfv" tells this to Qemu, and "-xen-domid 6" tells it >> which Xen domain to connect to. >> >> All HVM domains run with hardware virtualisation extensions, which are >> managed by Xen itself. > > Hi Andrew, > > Thanks for this response - to ensure I have this correct, there is no > need for qemu-upstream to build qemu-system-x86_64 as the CPU is > directly handled by Xen and not by qemu Correct. > - thereby passing through the capabilities of the CPU directly to the > guest. As such, as long as qemu starts on a 64 bit machine it will be > able to run 64 bit OS/kernel etc. Incorrect. A 32bit Qemu is perfectly able to emulate devices for a 64bit OS. The ABI of the emulated devices is not tied to the running width of Qemu or the OS. > > I ask this as I see a number of qemu packages that do include > qemu-system-x86_64 as well as qemu-system-i386 - which makes me seek > clarification. I would assume that these are just not built to use Xen > as the hypervisor for hardware acceleration? > This will just be down to the choice of the person who packaged qemu for a particular distro. ~Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary? 2016-02-05 0:12 ` Andrew Cooper @ 2016-02-05 9:56 ` Ian Campbell 0 siblings, 0 replies; 8+ messages in thread From: Ian Campbell @ 2016-02-05 9:56 UTC (permalink / raw) To: Andrew Cooper, Steven Haigh; +Cc: Alex Braunegg, xen-devel On Fri, 2016-02-05 at 00:12 +0000, Andrew Cooper wrote: > On 04/02/2016 23:14, Steven Haigh wrote: > > On 2016-02-05 09:22, Andrew Cooper wrote: > > > On 04/02/2016 22:06, Alex Braunegg wrote: > > > Qemu is only used for device emulation when used with Xen, not CPU > > > emulation. I answered Steve's original thread before I saw this and also added http://wiki.xenproject.org/wiki/QEMU_Upstream#Why_is_qemu-system-i386_used_even_on_x86_64_and_even_non-x86.3F to the wiki. If anyone things that anything mention in this subthread is worth recording there then please do update the wiki. Ian. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary? 2016-02-04 22:22 ` Andrew Cooper 2016-02-04 23:14 ` Steven Haigh @ 2016-02-04 23:44 ` Alex Braunegg 2016-02-05 0:04 ` Andrew Cooper 1 sibling, 1 reply; 8+ messages in thread From: Alex Braunegg @ 2016-02-04 23:44 UTC (permalink / raw) To: 'Andrew Cooper', xen-devel Hi Andrew, I don't know enough on the internals of xen / qemu here - however, based on what you said, an x86_64 OS with >4Gb memory should boot via xl - however in my case here it fails to start up: ------------------------------------------------------------- [root@mynas-s5000xvn ~]# xl -vvvv create /etc/xen/config/Windows_2008_R2.cfg Parsing config from /etc/xen/config/Windows_2008_R2.cfg libxl: debug: libxl_create.c:1560:do_domain_create: ao 0x735690: create: how=(nil) callback=(nil) poller=0x734b70 libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk vdev=hda, using backend phy libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk vdev=hdc spec.backend=unknown libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk vdev=hdc, using backend phy libxl: debug: libxl_create.c:945:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV domain, skipping bootloader libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch w=0x736078: deregister unregistered xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x5b3a4 xc: detail: elf_parse_binary: memory: 0x100000 -> 0x15b3a4 xc: detail: VIRTUAL MEMORY ARRANGEMENT: xc: detail: Loader: 0000000000100000->000000000015b3a4 xc: detail: Modules: 0000000000000000->0000000000000000 xc: detail: TOTAL: 0000000000000000->000000017f000000 xc: detail: ENTRY: 0000000000100600 xc: detail: PHYSICAL MEMORY ALLOCATION: xc: detail: 4KB PAGES: 0x0000000000000200 xc: detail: 2MB PAGES: 0x00000000000005f7 xc: detail: 1GB PAGES: 0x0000000000000003 xc: detail: elf_load_binary: phdr 0 at 0x7efc906d7000 -> 0x7efc90728910 xc: error: Could not clear special pages (22 = Invalid argument): Internal error libxl: error: libxl_dom.c:1003:libxl__build_hvm: hvm building failed libxl: error: libxl_create.c:1142:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl_dm.c:1956:kill_device_model: unable to find device model pid in /local/domain/11/image/device-model-pid libxl: error: libxl.c:1628:libxl__destroy_domid: libxl__destroy_device_model failed for 11 libxl: debug: libxl.c:1719:devices_destroy_cb: forked pid 18569 for destroy of domain 11 libxl: debug: libxl_create.c:1583:do_domain_create: ao 0x735690: inprogress: poller=0x734b70, flags=i libxl: debug: libxl_event.c:1874:libxl__ao_complete: ao 0x735690: complete, rc=-3 libxl: debug: libxl_event.c:1843:libxl__ao__destroy: ao 0x735690: destroy libxl: debug: libxl.c:1458:libxl_domain_destroy: ao 0x734bc0: create: how=(nil) callback=(nil) poller=0x734b70 libxl: error: libxl.c:1591:libxl__destroy_domid: non-existant domain 11 libxl: error: libxl.c:1549:domain_destroy_callback: unable to destroy guest with domid 11 libxl: error: libxl.c:1476:domain_destroy_cb: destruction of domain 11 failed libxl: debug: libxl_event.c:1874:libxl__ao_complete: ao 0x734bc0: complete, rc=-21 libxl: debug: libxl.c:1467:libxl_domain_destroy: ao 0x734bc0: inprogress: poller=0x734b70, flags=ic libxl: debug: libxl_event.c:1843:libxl__ao__destroy: ao 0x734bc0: destroy xc: debug: hypercall buffer: total allocations:851 total releases:851 xc: debug: hypercall buffer: current allocations:0 maximum allocations:3 xc: debug: hypercall buffer: cache current size:3 xc: debug: hypercall buffer: cache hits:841 misses:3 toobig:7 [root@mynas-s5000xvn ~]# ------------------------------------------------------------- Guest Config: ============= ------------------------------------------------------------- builder='hvm' memory = 6144 shadow_memory = 8 uuid = '27f4787c-89b2-46ab-a797-96ea6e84c511' name = 'Windows_2008_R2' vif = [ 'bridge=br0, mac=00:16:3e:96:49:10' ] disk = [ '/dev/zvol/storage0/xen/Windows_2008_R2/disk_sda,,hda','/storage0/data-share s/iso/en_windows_server_2008_r2_standard_enterprise_datacenter_and_web_x64_d vd_x15-59754.iso,,hdc,cdrom' ] # boot on floppy (a), hard disk (c) or CD-ROM (d) # default: hard disk, cd-rom, floppy boot='dc' sdl=0 vnc=1 vncconsole=1 vnclisten='0.0.0.0' stdvga=1 serial='pty' usbdevice='tablet' vncpasswd='bpC7fKtsDy' vncdisplay=2 localtime=1 audio='1' soundhw='ac97' ------------------------------------------------------------- xl info ------------------------------------------------------------- host : mynas-s5000xvn.localdomain release : 4.3.4-1.el6.x86_64 version : #1 SMP Wed Jan 27 13:05:22 EST 2016 machine : x86_64 nr_cpus : 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 1 cpu_mhz : 1861 hw_caps : bfebfbff:20100800:00000000:00000900:0004e3bd:00000000:00000001:00000000 virt_caps : hvm total_memory : 8165 free_memory : 7046 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 6 xen_extra : .0 xen_version : 4.6.0 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : xen_commandline : dom0_mem=1024M,max:1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin cc_compiler : gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) cc_compile_by : mockbuild cc_compile_domain : mynas.com.au cc_compile_date : Fri Jan 29 12:39:55 EST 2016 xend_config_format : 4 ------------------------------------------------------------- Best regards, Alex -----Original Message----- From: Andrew Cooper [mailto:amc96@hermes.cam.ac.uk] On Behalf Of Andrew Cooper Sent: Friday, 5 February 2016 9:22 AM To: Alex Braunegg; xen-devel@lists.xen.org Subject: Re: [Xen-devel] [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary? On 04/02/2016 22:06, Alex Braunegg wrote: > root 30511 46.4 0.1 398728 1860 ? RLsl 08:47 0:27 > /usr/lib/xen/bin/qemu-system-i386 -xen-domid 6 -chardev > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-6,server,n > owait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev > socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-6,server,nowait > -mon chardev=libxenstat-cmd,mode=control > -nodefaults -name test2 -vnc > 0.0.0.0:0,websocket,x509=/etc/pki/xen,password,to=99 -display none -serial > pty -device VGA,vgamem_mb=16 -boot order=cd -usb -usbdevice tablet -soundhw > ac97 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:f1:48:8c -netdev > type=tap,id=net0,ifname=vif6.0-emu,script=no,downscript=no -machine xenfv -m > 496 -drive file=/dev/zvol/stor > age0/xen/test2/disk_sda,if=ide,index=0,media=disk,format=raw,cache=writeback > -drive > file=/storage0/data-shares/iso/CentOS-6.5-x86_64-minimal.iso,if=ide,index=2, > readonly=on,media=c > drom,format=raw,cache=writeback,id=ide-5632 > > ------------------------------------------ > > So - to me it appears that xl is performing some sort of x86_64 -> i386/i686 > instruction translation to make things work. > > Would this not be introducing a performance impediment by having some sort > of extra translation processing going on between xl and the qemu binary? Qemu is only used for device emulation when used with Xen, not CPU emulation. The "-machine xenfv" tells this to Qemu, and "-xen-domid 6" tells it which Xen domain to connect to. All HVM domains run with hardware virtualisation extensions, which are managed by Xen itself. ~Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary? 2016-02-04 23:44 ` Alex Braunegg @ 2016-02-05 0:04 ` Andrew Cooper 2016-02-05 0:18 ` Alex Braunegg 0 siblings, 1 reply; 8+ messages in thread From: Andrew Cooper @ 2016-02-05 0:04 UTC (permalink / raw) To: Alex Braunegg, xen-devel On 04/02/2016 23:44, Alex Braunegg wrote: > Hi Andrew, > > I don't know enough on the internals of xen / qemu here - however, based on > what you said, an x86_64 OS with >4Gb memory should boot via xl - however in > my case here it fails to start up: > > ------------------------------------------------------------- > > [root@mynas-s5000xvn ~]# xl -vvvv create /etc/xen/config/Windows_2008_R2.cfg > > Parsing config from /etc/xen/config/Windows_2008_R2.cfg > libxl: debug: libxl_create.c:1560:do_domain_create: ao 0x735690: create: > how=(nil) callback=(nil) poller=0x734b70 > libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk > vdev=hda spec.backend=unknown > libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk > vdev=hda, using backend phy > libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk > vdev=hdc spec.backend=unknown > libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk > vdev=hdc, using backend phy > libxl: debug: libxl_create.c:945:initiate_domain_create: running bootloader > libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV domain, > skipping bootloader > libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch > w=0x736078: deregister unregistered > xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x5b3a4 > xc: detail: elf_parse_binary: memory: 0x100000 -> 0x15b3a4 > xc: detail: VIRTUAL MEMORY ARRANGEMENT: > xc: detail: Loader: 0000000000100000->000000000015b3a4 > xc: detail: Modules: 0000000000000000->0000000000000000 > xc: detail: TOTAL: 0000000000000000->000000017f000000 > xc: detail: ENTRY: 0000000000100600 > xc: detail: PHYSICAL MEMORY ALLOCATION: > xc: detail: 4KB PAGES: 0x0000000000000200 > xc: detail: 2MB PAGES: 0x00000000000005f7 > xc: detail: 1GB PAGES: 0x0000000000000003 > xc: detail: elf_load_binary: phdr 0 at 0x7efc906d7000 -> 0x7efc90728910 > xc: error: Could not clear special pages (22 = Invalid argument): Internal > error > libxl: error: libxl_dom.c:1003:libxl__build_hvm: hvm building failed The problem is here, but it isn't immediately apparent why (other than "failed to map special pages"). > Guest Config: > ============= > > ------------------------------------------------------------- > > builder='hvm' > memory = 6144 > shadow_memory = 8 These values look suspicious to me. What hardware is this running on? Either you are on more modern hardware and shouldn't touch shadow_memory, or you are on rather older hardware, at which point 8M of shadow memory is probably too small for a 6G VM. ~Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary? 2016-02-05 0:04 ` Andrew Cooper @ 2016-02-05 0:18 ` Alex Braunegg 0 siblings, 0 replies; 8+ messages in thread From: Alex Braunegg @ 2016-02-05 0:18 UTC (permalink / raw) To: 'Andrew Cooper', xen-devel Hi Andrew, The Windows 2008 .cfg was built up using guidance from http://www.virtuatopia.com/index.php/Virtualizing_Windows_Server_2008_with_X en If shadow_memory is not required - easy enough remove and retest. (which after removing this line, the guest started without issue) The physical server itself is an Intel S5000xvn motherboard with 2 x E5320 CPU's: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU E5320 @ 1.86GHz stepping : 7 microcode : 0x69 cpu MHz : 1861.990 cache size : 4096 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc arch_perfmon rep_good nopl pni monitor est ssse3 cx16 hypervisor lahf_lm dtherm bugs : bogomips : 3723.98 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: Best regards, Alex -----Original Message----- From: Andrew Cooper [mailto:amc96@hermes.cam.ac.uk] On Behalf Of Andrew Cooper Sent: Friday, 5 February 2016 11:04 AM To: Alex Braunegg; xen-devel@lists.xen.org Subject: Re: [Xen-devel] [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary? On 04/02/2016 23:44, Alex Braunegg wrote: > Hi Andrew, > > I don't know enough on the internals of xen / qemu here - however, based on > what you said, an x86_64 OS with >4Gb memory should boot via xl - however in > my case here it fails to start up: > > ------------------------------------------------------------- > > [root@mynas-s5000xvn ~]# xl -vvvv create /etc/xen/config/Windows_2008_R2.cfg > > Parsing config from /etc/xen/config/Windows_2008_R2.cfg > libxl: debug: libxl_create.c:1560:do_domain_create: ao 0x735690: create: > how=(nil) callback=(nil) poller=0x734b70 > libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk > vdev=hda spec.backend=unknown > libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk > vdev=hda, using backend phy > libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk > vdev=hdc spec.backend=unknown > libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk > vdev=hdc, using backend phy > libxl: debug: libxl_create.c:945:initiate_domain_create: running bootloader > libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV domain, > skipping bootloader > libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch > w=0x736078: deregister unregistered > xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x5b3a4 > xc: detail: elf_parse_binary: memory: 0x100000 -> 0x15b3a4 > xc: detail: VIRTUAL MEMORY ARRANGEMENT: > xc: detail: Loader: 0000000000100000->000000000015b3a4 > xc: detail: Modules: 0000000000000000->0000000000000000 > xc: detail: TOTAL: 0000000000000000->000000017f000000 > xc: detail: ENTRY: 0000000000100600 > xc: detail: PHYSICAL MEMORY ALLOCATION: > xc: detail: 4KB PAGES: 0x0000000000000200 > xc: detail: 2MB PAGES: 0x00000000000005f7 > xc: detail: 1GB PAGES: 0x0000000000000003 > xc: detail: elf_load_binary: phdr 0 at 0x7efc906d7000 -> 0x7efc90728910 > xc: error: Could not clear special pages (22 = Invalid argument): Internal > error > libxl: error: libxl_dom.c:1003:libxl__build_hvm: hvm building failed The problem is here, but it isn't immediately apparent why (other than "failed to map special pages"). > Guest Config: > ============= > > ------------------------------------------------------------- > > builder='hvm' > memory = 6144 > shadow_memory = 8 These values look suspicious to me. What hardware is this running on? Either you are on more modern hardware and shouldn't touch shadow_memory, or you are on rather older hardware, at which point 8M of shadow memory is probably too small for a 6G VM. ~Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-02-05 9:56 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-02-04 22:06 [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary? Alex Braunegg 2016-02-04 22:22 ` Andrew Cooper 2016-02-04 23:14 ` Steven Haigh 2016-02-05 0:12 ` Andrew Cooper 2016-02-05 9:56 ` Ian Campbell 2016-02-04 23:44 ` Alex Braunegg 2016-02-05 0:04 ` Andrew Cooper 2016-02-05 0:18 ` Alex Braunegg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).