From: "Alex Braunegg" <alex.braunegg@gmail.com>
To: 'Andrew Cooper' <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [QUESTION] x86_64 -> i386/i686 CPU translation between xl and qemu binary?
Date: Fri, 5 Feb 2016 11:18:45 +1100 [thread overview]
Message-ID: <56b3ea6c.283f420a.f4428.ffffbbca@mx.google.com> (raw)
In-Reply-To: <56B3E6F9.7010007@citrix.com>
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
prev parent reply other threads:[~2016-02-05 0:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56b3ea6c.283f420a.f4428.ffffbbca@mx.google.com \
--to=alex.braunegg@gmail.com \
--cc=andrew.cooper3@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.