Re: [Xen-users] xl create bug on first-attempt with passthrough

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

Please can you keep the ML in the loop. I have added it back this time.

On Mon, 2012-09-24 at 10:23 +0100, Casey DeLorme wrote:
> Sorry it was not intentional, gmail automatically positions my
> response above the last message.

So please move the cursor before you start typing. This will also give
you the opportunity to trim your quotes to the appropriate amount of
context.


> First attempt after rebooting the platform running "xl -vvv
> create /etc/xen/windows.cfg" yields:
> 
> cdelorme@xen:~$ xl -vvv create /etc/xen/windows.cfg
> Parsing config from /etc/xen/windows.cfg
> libxl: debug: libxl_create.c:1173:do_domain_create: ao 0x1480890: create: 
> how=(nil) callback=(nil) poller=0x1480b80
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
> vdev=hda spec.backend=unknown
> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
> vdev=hda, using backend phy
> libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader
> libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV domain, 
> skipping bootloader
> libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch 
> w=0x1481bd0: deregister unregistered
> libxl: notice: libxl_numa.c:451:libxl__get_numa_candidate: NUMA placement 
> failed, performance might be affected
> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9df08
> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19df08
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000019df08
>   TOTAL:         0000000000000000->00000001ff000000
>   ENTRY ADDRESS: 0000000000100000
> xc: detail: Failed allocation for dom 1: 2048 extents of order 0
> xc: error: Could not allocate memory for HVM guest. (16 = Device or resource 
> busy): Internal error

Here is your actual error message.

I have two guesses as to what is happening here.

First is that, for some reason, dom0 is too slow to balloon down and xl
has failed to notice this somehow. By the time you run your second
domain domain 0 has caught up.

The other option is that perhaps xl is underestimating the RAM required
to start the domain (perhaps passthrough adds some additional memory
overhead which it doesn't correctly account for) but by making room for
this first domain it inadvertently adds enough slack to the system that
a starting the second time succeeds. If this is the case then there is a
second order bug here which is that xl didn't balloon backup after the
initial domain create failed.

Either way this sounds like a bug in xl's autoballooning code, it would
be useful to report as such on xen-devel.

One obvious solution/workaround would be to use the dom0_mem option and
disable auto ballooning.

Ian.



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