CC'ing Gerd and the seabios list:
On 08/13/13 11:16, Fabio Fantoni wrote:
Il 12/08/2013 17:04, Fabio Fantoni ha scritto:
Dom0: Wheezy 64 bit with kernel from package linux-image-3.2.0-4-amd64 version 3.2.46-1 and all dependency packages for xen, spice and usb redirection. Seabios 1.7.3-1, qemu 1.5.0+dfsg-5 (1.5.1), spice 0.12.4-0nocelt1 and usbredir 0.6-2 compiled from debian unstable sources.
git clone git://xenbits.xen.org/xen.git (in this build commit is 73f18583dd824f0e49f65149ef603600ce31b8ee)
Added some patches:
- tools-configure-qemu-for-spice-and-usbredir
- libxl-Add-spice-vdagent-support-for-upstream-qemu v3
- libxl: usb2 and usb3 controller support for upstream qemu v4
- tools-firmware-seabios-packaged
- tools: Improve make deb v3
- tools: remove or disable old/useless/unused/unmainted stuff (the
whole series of 9 patches)
./configure --prefix=/usr --disable-xend
make debball
New issue:
- domU not start with qemu 1.5.1 and more that 2 gb of ram: tested on w7 64 bit domU with 4 gb of ram, with built-in qemu 1.3 it
works, while with qemu 1.5.1 doesn't (stops at the beginning, spice client show only the lines of seabios version and machine UUID; qemu log show nothing more that 2 gb test), while with 2 gb of ram works also with qemu 1.5.1
Added qemu-devel and debian maintainers to cc for this regression about upstream qemu. If you need more details and tests tell me and I'll do/post them.
As a superficial guess, this could be fixed by the seabios-1.7.3.1 release:
http://thread.gmane.org/gmane.comp.emulators.qemu/227536
http://code.coreboot.org/p/seabios/source/commit/2a9aeabdfb34374ecac25e7a8d2...
Laszlo
Old issue:
- Network is not working after restore on Windows domU with qemu-xen
and gplpv Workaround: fixed mac address
- Starting xendomain with "xl create" show some debug options: Starting auto Xen domains: W7.cfgxc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019eb68 Modules: 0000000000000000->0000000000000000 TOTAL: 0000000000000000->000000007f000000 ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003f7 1GB PAGES: 0x0000000000000000 [done]. I think it is would be better hiding them here
- on W7 pro 64 bit domU error in the begin of qemu log, while domU
seem to work: xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22 = Invalid argument): Internal error xen be: qdisk-832: xc_gnttab_set_max_grants failed: Invalid argument
- nested hvm was bugged: started test it on windows 7 pro 64 domU on
qemu-xen, xpmode crashed on install without show error, no error on logs and havdetection works Now xpmode install and start correctly except integration features (disks,printers,clipboard sharing) and usb passthrough (of xpmode)
Il 13/08/2013 12:04, Laszlo Ersek ha scritto:
CC'ing Gerd and the seabios list:
On 08/13/13 11:16, Fabio Fantoni wrote:
Il 12/08/2013 17:04, Fabio Fantoni ha scritto:
Dom0: Wheezy 64 bit with kernel from package linux-image-3.2.0-4-amd64 version 3.2.46-1 and all dependency packages for xen, spice and usb redirection. Seabios 1.7.3-1, qemu 1.5.0+dfsg-5 (1.5.1), spice 0.12.4-0nocelt1 and usbredir 0.6-2 compiled from debian unstable sources.
git clone git://xenbits.xen.org/xen.git (in this build commit is 73f18583dd824f0e49f65149ef603600ce31b8ee)
Added some patches:
- tools-configure-qemu-for-spice-and-usbredir
- libxl-Add-spice-vdagent-support-for-upstream-qemu v3
- libxl: usb2 and usb3 controller support for upstream qemu v4
- tools-firmware-seabios-packaged
- tools: Improve make deb v3
- tools: remove or disable old/useless/unused/unmainted stuff (the
whole series of 9 patches)
./configure --prefix=/usr --disable-xend
make debball
New issue:
- domU not start with qemu 1.5.1 and more that 2 gb of ram: tested on w7 64 bit domU with 4 gb of ram, with built-in qemu 1.3 it
works, while with qemu 1.5.1 doesn't (stops at the beginning, spice client show only the lines of seabios version and machine UUID; qemu log show nothing more that 2 gb test), while with 2 gb of ram works also with qemu 1.5.1
Added qemu-devel and debian maintainers to cc for this regression about upstream qemu. If you need more details and tests tell me and I'll do/post them.
As a superficial guess, this could be fixed by the seabios-1.7.3.1 release:
http://thread.gmane.org/gmane.comp.emulators.qemu/227536
http://code.coreboot.org/p/seabios/source/commit/2a9aeabdfb34374ecac25e7a8d2...
Laszlo
Thanks for reply, i did fast test adding this patch that you linked: http://code.coreboot.org/p/seabios/source/commit/2a9aeabdfb34374ecac25e7a8d2... Same result, the problem remains, should I test full seabios 1.7.3.1?
Old issue:
- Network is not working after restore on Windows domU with qemu-xen
and gplpv Workaround: fixed mac address
- Starting xendomain with "xl create" show some debug options: Starting auto Xen domains: W7.cfgxc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019eb68 Modules: 0000000000000000->0000000000000000 TOTAL: 0000000000000000->000000007f000000 ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003f7 1GB PAGES: 0x0000000000000000 [done]. I think it is would be better hiding them here
- on W7 pro 64 bit domU error in the begin of qemu log, while domU
seem to work: xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22 = Invalid argument): Internal error xen be: qdisk-832: xc_gnttab_set_max_grants failed: Invalid argument
- nested hvm was bugged: started test it on windows 7 pro 64 domU on
qemu-xen, xpmode crashed on install without show error, no error on logs and havdetection works Now xpmode install and start correctly except integration features (disks,printers,clipboard sharing) and usb passthrough (of xpmode)
On 08/13/13 12:33, Fabio Fantoni wrote:
Il 13/08/2013 12:04, Laszlo Ersek ha scritto:
CC'ing Gerd and the seabios list:
On 08/13/13 11:16, Fabio Fantoni wrote:
Il 12/08/2013 17:04, Fabio Fantoni ha scritto:
New issue:
- domU not start with qemu 1.5.1 and more that 2 gb of ram: tested on w7 64 bit domU with 4 gb of ram, with built-in qemu 1.3 it
works, while with qemu 1.5.1 doesn't (stops at the beginning, spice client show only the lines of seabios version and machine UUID; qemu log show nothing more that 2 gb test), while with 2 gb of ram works also with qemu 1.5.1
Added qemu-devel and debian maintainers to cc for this regression about upstream qemu. If you need more details and tests tell me and I'll do/post them.
As a superficial guess, this could be fixed by the seabios-1.7.3.1 release:
http://thread.gmane.org/gmane.comp.emulators.qemu/227536
http://code.coreboot.org/p/seabios/source/commit/2a9aeabdfb34374ecac25e7a8d2...
Laszlo
Thanks for reply, i did fast test adding this patch that you linked: http://code.coreboot.org/p/seabios/source/commit/2a9aeabdfb34374ecac25e7a8d2...
Same result, the problem remains, should I test full seabios 1.7.3.1?
No idea, it was just a random shot, sorry... You're probably down to bisecting qemu :(
Laszlo
Il 13/08/2013 13:09, Laszlo Ersek ha scritto:
On 08/13/13 12:33, Fabio Fantoni wrote:
Il 13/08/2013 12:04, Laszlo Ersek ha scritto:
CC'ing Gerd and the seabios list:
On 08/13/13 11:16, Fabio Fantoni wrote:
Il 12/08/2013 17:04, Fabio Fantoni ha scritto:
New issue:
- domU not start with qemu 1.5.1 and more that 2 gb of ram: tested on w7 64 bit domU with 4 gb of ram, with built-in qemu 1.3 it
works, while with qemu 1.5.1 doesn't (stops at the beginning, spice client show only the lines of seabios version and machine UUID; qemu log show nothing more that 2 gb test), while with 2 gb of ram works also with qemu 1.5.1
Added qemu-devel and debian maintainers to cc for this regression about upstream qemu. If you need more details and tests tell me and I'll do/post them.
As a superficial guess, this could be fixed by the seabios-1.7.3.1 release:
http://thread.gmane.org/gmane.comp.emulators.qemu/227536
http://code.coreboot.org/p/seabios/source/commit/2a9aeabdfb34374ecac25e7a8d2...
Laszlo
Thanks for reply, i did fast test adding this patch that you linked: http://code.coreboot.org/p/seabios/source/commit/2a9aeabdfb34374ecac25e7a8d2...
Same result, the problem remains, should I test full seabios 1.7.3.1?
No idea, it was just a random shot, sorry... You're probably down to bisecting qemu :(
Laszlo
I did another test disabling the usb controller: it didn't find any bootable disk and tried to boot with pxe. I also tried F12 and it reported an hard-disk size of 0 MB. Configuration is correct because if I change the ram size to 2 GB instead of 4, it starts correctly. No additional information from qemu log. I tried also seabios 1.7.2.2 and master from git, both with same result.
On Tue, Aug 13, 2013 at 03:26:43PM +0200, Fabio Fantoni wrote:
Il 13/08/2013 13:09, Laszlo Ersek ha scritto:
On 08/13/13 12:33, Fabio Fantoni wrote:
Il 13/08/2013 12:04, Laszlo Ersek ha scritto:
On 08/13/13 11:16, Fabio Fantoni wrote:
Il 12/08/2013 17:04, Fabio Fantoni ha scritto:
New issue:
- domU not start with qemu 1.5.1 and more that 2 gb of ram: tested on w7 64 bit domU with 4 gb of ram, with built-in qemu 1.3 it
works, while with qemu 1.5.1 doesn't (stops at the beginning, spice client show only the lines of seabios version and machine UUID; qemu log show nothing more that 2 gb test), while with 2 gb of ram works also with qemu 1.5.1
[...]
I did another test disabling the usb controller: it didn't find any bootable disk and tried to boot with pxe. I also tried F12 and it reported an hard-disk size of 0 MB. Configuration is correct because if I change the ram size to 2 GB instead of 4, it starts correctly. No additional information from qemu log. I tried also seabios 1.7.2.2 and master from git, both with same result.
It's not clear to me if this is a QEMU issue or SeaBIOS issue. Can you arrange to run qemu with the following added to the command line:
-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
and post the full log from a successful (2G) boot as well as the unsuccessful (4G) boot?
-Kevin
Il 14/08/2013 01:58, Kevin O'Connor ha scritto:
On Tue, Aug 13, 2013 at 03:26:43PM +0200, Fabio Fantoni wrote:
Il 13/08/2013 13:09, Laszlo Ersek ha scritto:
On 08/13/13 12:33, Fabio Fantoni wrote:
Il 13/08/2013 12:04, Laszlo Ersek ha scritto:
On 08/13/13 11:16, Fabio Fantoni wrote:
Il 12/08/2013 17:04, Fabio Fantoni ha scritto: > New issue: > - domU not start with qemu 1.5.1 and more that 2 gb of ram: > tested on w7 64 bit domU with 4 gb of ram, with built-in qemu 1.3 it > works, > while with qemu 1.5.1 doesn't (stops at the beginning, spice client > show only the lines of seabios version and machine UUID; > qemu log show nothing more that 2 gb test), while with 2 gb of ram > works also with qemu 1.5.1 > -------------------------
[...]
I did another test disabling the usb controller: it didn't find any bootable disk and tried to boot with pxe. I also tried F12 and it reported an hard-disk size of 0 MB. Configuration is correct because if I change the ram size to 2 GB instead of 4, it starts correctly. No additional information from qemu log. I tried also seabios 1.7.2.2 and master from git, both with same result.
It's not clear to me if this is a QEMU issue or SeaBIOS issue. Can you arrange to run qemu with the following added to the command line:
-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
and post the full log from a successful (2G) boot as well as the unsuccessful (4G) boot?
-Kevin
Tried qemu 1.6.0-rc3, hvm domU does not start in any case because qemu crashes on start
------------------------------------ xl create /etc/xen/W7.cfg ------------------------------------ Parsing config from /etc/xen/W7.cfg xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019ee88 Modules: 0000000000000000->0000000000000000 TOTAL: 0000000000000000->000000007f000000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003f7 1GB PAGES: 0x0000000000000000 libxl: error: libxl_dm.c:1313:device_model_spawn_outcome: domain 1 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1079:domcreate_devmodel_started: device model did not start: -3 libxl: error: libxl_dm.c:1344:libxl__destroy_device_model: Device Model already exited ------------------------------------
------------------------------------ /var/log/xen/qemu-dm-W7.log ------------------------------------ xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22 = Invalid argument): Internal error xen be: qdisk-768: xc_gnttab_set_max_grants failed: Invalid argument xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22 = Invalid argument): Internal error xen be: qdisk-832: xc_gnttab_set_max_grants failed: Invalid argument ------------------------------------
Tried with qemu 1.4.2 and it works also with 4 gb of ram. This ram regression seems to be introduced with qemu 1.5, and there is another regression more critical with qemu 1.6.
Tried to add seabios debug options to domU xl configuration file...
device_model_args=["-chardev stdio,id=seabios","-device","isa-debugcon,iobase=0x402,chardev=seabios"]
But it doesn't boot
/var/log/xen/qemu-dm-W7.log qemu-system-x86_64: -chardev stdio,id=seabios: invalid option
On 08/14/13 11:19, Fabio Fantoni wrote:
Tried with qemu 1.4.2 and it works also with 4 gb of ram. This ram regression seems to be introduced with qemu 1.5, and there is another regression more critical with qemu 1.6.
Can you save qemu's stderr for the 1.5->1.6 regression?
Tried to add seabios debug options to domU xl configuration file...
device_model_args=["-chardev stdio,id=seabios","-device","isa-debugcon,iobase=0x402,chardev=seabios"]
But it doesn't boot
/var/log/xen/qemu-dm-W7.log qemu-system-x86_64: -chardev stdio,id=seabios: invalid option
That's probably because you forgot to break up this option into separate python list entries:
device_model_args=["-chardev", "stdio,id=seabios", "-device", "isa-debugcon,iobase=0x402,chardev=seabios"]
Laszlo
Il 14/08/2013 11:56, Laszlo Ersek ha scritto:
On 08/14/13 11:19, Fabio Fantoni wrote:
Tried with qemu 1.4.2 and it works also with 4 gb of ram. This ram regression seems to be introduced with qemu 1.5, and there is another regression more critical with qemu 1.6.
Can you save qemu's stderr for the 1.5->1.6 regression?
Tried to add seabios debug options to domU xl configuration file...
device_model_args=["-chardev stdio,id=seabios","-device","isa-debugcon,iobase=0x402,chardev=seabios"]
But it doesn't boot
/var/log/xen/qemu-dm-W7.log qemu-system-x86_64: -chardev stdio,id=seabios: invalid option
That's probably because you forgot to break up this option into separate python list entries:
device_model_args=["-chardev", "stdio,id=seabios", "-device", "isa-debugcon,iobase=0x402,chardev=seabios"]
Laszlo
Thanks for your reply and sorry for my very stupid error. I retried with the correct parameters and on both cases (2 gb of ram working and 4gb of ram not working) I get only this one more line on qemu log: Start bios (version debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-test)
The probable cause is that on xen, seabios doesn't generate some tables but it takes the static ones from hvmloader.
On 08/14/13 12:54, Fabio Fantoni wrote:
Il 14/08/2013 11:56, Laszlo Ersek ha scritto:
On 08/14/13 11:19, Fabio Fantoni wrote:
Tried with qemu 1.4.2 and it works also with 4 gb of ram. This ram regression seems to be introduced with qemu 1.5, and there is another regression more critical with qemu 1.6.
Can you save qemu's stderr for the 1.5->1.6 regression?
Tried to add seabios debug options to domU xl configuration file...
device_model_args=["-chardev stdio,id=seabios","-device","isa-debugcon,iobase=0x402,chardev=seabios"]
But it doesn't boot
/var/log/xen/qemu-dm-W7.log qemu-system-x86_64: -chardev stdio,id=seabios: invalid option
That's probably because you forgot to break up this option into separate python list entries:
device_model_args=["-chardev", "stdio,id=seabios", "-device", "isa-debugcon,iobase=0x402,chardev=seabios"]
Laszlo
Thanks for your reply and sorry for my very stupid error. I retried with the correct parameters and on both cases (2 gb of ram working and 4gb of ram not working) I get only this one more line on qemu log: Start bios (version debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-test)
The probable cause is that on xen, seabios doesn't generate some tables but it takes the static ones from hvmloader.
Without having any specifics in mind, maybe this can be attributed to the ACPI table move that affects both qemu and seabios, and hvmloader is the collateral damage. Probably stuff should be updated in qemu/seabios so that hvmloader be happy again. CC'ing Michael...
Of course I might as well be completely off.
Laszlo
On Wed, Aug 14, 2013 at 01:16:24PM +0200, Laszlo Ersek wrote:
On 08/14/13 12:54, Fabio Fantoni wrote:
Il 14/08/2013 11:56, Laszlo Ersek ha scritto:
On 08/14/13 11:19, Fabio Fantoni wrote:
Tried with qemu 1.4.2 and it works also with 4 gb of ram. This ram regression seems to be introduced with qemu 1.5, and there is another regression more critical with qemu 1.6.
Can you save qemu's stderr for the 1.5->1.6 regression?
Tried to add seabios debug options to domU xl configuration file...
device_model_args=["-chardev stdio,id=seabios","-device","isa-debugcon,iobase=0x402,chardev=seabios"]
But it doesn't boot
/var/log/xen/qemu-dm-W7.log qemu-system-x86_64: -chardev stdio,id=seabios: invalid option
That's probably because you forgot to break up this option into separate python list entries:
device_model_args=["-chardev", "stdio,id=seabios", "-device", "isa-debugcon,iobase=0x402,chardev=seabios"]
Laszlo
Thanks for your reply and sorry for my very stupid error. I retried with the correct parameters and on both cases (2 gb of ram working and 4gb of ram not working) I get only this one more line on qemu log: Start bios (version debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-test)
The probable cause is that on xen, seabios doesn't generate some tables but it takes the static ones from hvmloader.
Without having any specifics in mind, maybe this can be attributed to the ACPI table move that affects both qemu and seabios, and hvmloader is the collateral damage. Probably stuff should be updated in qemu/seabios so that hvmloader be happy again. CC'ing Michael...
Of course I might as well be completely off.
Laszlo
Seems unlikely - the ACPI table move code is still in my tree.
Il 14/08/2013 13:21, Michael S. Tsirkin ha scritto:
On Wed, Aug 14, 2013 at 01:16:24PM +0200, Laszlo Ersek wrote:
On 08/14/13 12:54, Fabio Fantoni wrote:
Il 14/08/2013 11:56, Laszlo Ersek ha scritto:
On 08/14/13 11:19, Fabio Fantoni wrote:
Tried with qemu 1.4.2 and it works also with 4 gb of ram. This ram regression seems to be introduced with qemu 1.5, and there is another regression more critical with qemu 1.6.
Can you save qemu's stderr for the 1.5->1.6 regression?
Tried to add seabios debug options to domU xl configuration file...
device_model_args=["-chardev stdio,id=seabios","-device","isa-debugcon,iobase=0x402,chardev=seabios"]
But it doesn't boot
/var/log/xen/qemu-dm-W7.log qemu-system-x86_64: -chardev stdio,id=seabios: invalid option
That's probably because you forgot to break up this option into separate python list entries:
device_model_args=["-chardev", "stdio,id=seabios", "-device", "isa-debugcon,iobase=0x402,chardev=seabios"]
Laszlo
Thanks for your reply and sorry for my very stupid error. I retried with the correct parameters and on both cases (2 gb of ram working and 4gb of ram not working) I get only this one more line on qemu log: Start bios (version debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-test)
The probable cause is that on xen, seabios doesn't generate some tables but it takes the static ones from hvmloader.
Without having any specifics in mind, maybe this can be attributed to the ACPI table move that affects both qemu and seabios, and hvmloader is the collateral damage. Probably stuff should be updated in qemu/seabios so that hvmloader be happy again. CC'ing Michael...
Of course I might as well be completely off.
Laszlo
Seems unlikely - the ACPI table move code is still in my tree.
I see on 1.6 changelog:
... QEMU can expose the full set of ACPI tables to the guest: See Features/ACPITableGeneration http://wiki.qemu.org/Features/ACPITableGeneration ...
Could be this the regression problem of 1.6?
On Wed, Aug 14, 2013 at 12:54:06PM +0200, Fabio Fantoni wrote:
I retried with the correct parameters and on both cases (2 gb of ram working and 4gb of ram not working) I get only this one more line on qemu log: Start bios (version debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-test)
Xen moves the debug port to 0xe9 - can you try again with iobase=0xe9. (There should be some way to tell xen to log 0xe9 on its own, but I'm not familiar with xen.)
-Kevin
Il 14/08/2013 14:29, Kevin O'Connor ha scritto:
On Wed, Aug 14, 2013 at 12:54:06PM +0200, Fabio Fantoni wrote:
I retried with the correct parameters and on both cases (2 gb of ram working and 4gb of ram not working) I get only this one more line on qemu log: Start bios (version debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-test)
Xen moves the debug port to 0xe9 - can you try again with iobase=0xe9. (There should be some way to tell xen to log 0xe9 on its own, but I'm not familiar with xen.)
-Kevin
Thanks for reply. I tried with this: device_model_args=["-chardev","stdio,id=seabios","-device","isa-debugcon,iobase=0xe9,chardev=seabios"]
No more lines in qemu log are written and also "Start bios" line does not appair any more.
-
Fabio Fantoni -
Kevin O'Connor -
Laszlo Ersek -
Michael S. Tsirkin