[QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Alex Braunegg]

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

Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Andrew Cooper]

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

Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Steven Haigh]

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

Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Alex Braunegg]

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

Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Andrew Cooper]

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

Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Andrew Cooper]

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

Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Alex Braunegg]

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

Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?

[Ian Campbell]

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.