qemu-kvm-0.12.0-rc2 released
qemu-kvm-0.12.0-rc2 is now available. This release is is based on the upstream qemu 0.12.0-rc2, plus kvm-specific enhancements. Please see the original qemu 0.12.0-rc2 release announcement for details.
This release can be used with the kvm kernel modules provided by your distribution kernel, or by the modules in the kvm-kmod package, such as kvm-kmod-2.6.32.
Please give test this release out so we can enjoy a stable 0.12.0 final release.
[1] http://www.mail-archive.com/[email protected]/msg20151.html
Signature · 1 line
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Quoted 10 lines · Avi Kivity
qemu-kvm-0.12.0-rc2 is now available. This release is is based on the upstream qemu 0.12.0-rc2, plus kvm-specific enhancements. Please see the original qemu 0.12.0-rc2 release announcement for details.
This release can be used with the kvm kernel modules provided by your distribution kernel, or by the modules in the kvm-kmod package, such as kvm-kmod-2.6.32.
Please give test this release out so we can enjoy a stable 0.12.0 final release.
Hi Avi/Anthony-
I'm working on the packaging updates for Ubuntu Lucid, and I'm having trouble with the BIOS bits of qemu-kvm.
It seems that a fair amount of the BIOS submodules are missing.
The roms/ tree is basically empty.
I see some of the necessary bits in pc-bios/ and in kvm/vgabios/, but not enough here to build a usable qemu-kvm-0.12.0~rc2 package yet.
:-Dustin
Quoted 9 lines · Dustin Kirkland
I'm working on the packaging updates for Ubuntu Lucid, and I'm having trouble with the BIOS bits of qemu-kvm.
It seems that a fair amount of the BIOS submodules are missing.
The roms/ tree is basically empty.
Well, binaries are shipped, but I guess you'd like to build from source.
We have several options:
- do nothing
- ship a generated SOURCES file which contains git URLs and commit hashes, rely on the interested user to fetch and build. Also tag the submodules appropriately.
- fetch the submodules and include them in the tarball
- build separate tarballs for the submodules
Since packages are few I favour the second option, which is easiest for me.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 4 lines · Avi Kivity
Well, binaries are shipped, but I guess you'd like to build from source.
We have several options:
Quoted 8 lines
- do nothing
- ship a generated SOURCES file which contains git URLs and commit hashes, rely on the interested user to fetch and build. Also tag the submodules appropriately.
- fetch the submodules and include them in the tarball
- build separate tarballs for the submodulesSince packages are few I favour the second option, which is easiest for me.
Option three would seem to be the least work for anyone building from source, and also how sources are normally distributed.
If it needs specific versions of those modules to work and they don't have releases of their own you can point to, then they should probably be included.
Signature · 1 line
Len Sorensen
Quoted 11 lines · Avi Kivity
Quoted 9 lines · Dustin Kirkland
I'm working on the packaging updates for Ubuntu Lucid, and I'm having trouble with the BIOS bits of qemu-kvm.
It seems that a fair amount of the BIOS submodules are missing.
The roms/ tree is basically empty.
Quoted 8 lines
Well, binaries are shipped, but I guess you'd like to build from source.
We have several options:
- do nothing
- ship a generated SOURCES file which contains git URLs and commit
hashes, rely on the interested user to fetch and build. Also tag the submodules appropriately.
- fetch the submodules and include them in the tarball
I was thinking of taking this approach.
As we integrate the build environments, this will allow a user to do a make and it will build all of the roms from source by default.
Regards,
Anthony Liguori
Quoted 1 line · Avi Kivity
Well, binaries are shipped, but I guess you'd like to build from source.
Right, sorry I was ambiguous.
Quoted 1 line
We have several options:
...
Quoted 1 line
- fetch the submodules and include them in the tarball
...
I think this option would help keep us all on the same page. But I could live with pointers to the submodules, since packaging a new release only happens a couple of times per year.
:-Dustin
Quoted 5 lines · Dustin Kirkland
Quoted 1 line · Avi Kivity
Well, binaries are shipped, but I guess you'd like to build from source.
Right, sorry I was ambiguous.
Quoted 8 lines
Quoted 1 line
We have several options:
...
Quoted 1 line
- fetch the submodules and include them in the tarball
...
I think this option would help keep us all on the same page. But I could live with pointers to the submodules, since packaging a new release only happens a couple of times per year.
Okay, I pulled the submodules myself for now, just to get the packaging going.
Unfortunately, I've hit a build error, for the arm-softmmu.
Snippet:
....
CC arm-softmmu/i386-dis.o AR arm-softmmu/libqemu.a LINK arm-softmmu/qemu-system-arm
monitor.o: In function `mon_get_cpu':
/local/source/qemu-kvm/lucid/qemu-kvm_0.12.0/monitor.c:675: undefined reference to `kvm_save_mpstate'
monitor.o: In function `do_info_cpus':
/local/source/qemu-kvm/lucid/qemu-kvm_0.12.0/monitor.c:778: undefined reference to `kvm_save_mpstate'
collect2: ld returned 1 exit status
Full log attached.
:-Dustin
Quoted 10 lines · Dustin Kirkland
Quoted 3 lines
- fetch the submodules and include them in the tarball
...
I think this option would help keep us all on the same page. But I could live with pointers to the submodules, since packaging a new release only happens a couple of times per year.
Due to time constraints I went for the simpler option of adding a generated EXTERNAL_DEPENDENCIES file. Patches for including the source are welcome.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 7 lines · Avi Kivity
Quoted 6 lines · Dustin Kirkland
Quoted 3 lines
- fetch the submodules and include them in the tarball
...
Quoted 8 lines
Quoted 5 lines
I think this option would help keep us all on the same page. But I could live with pointers to the submodules, since packaging a new release only happens a couple of times per year.
Due to time constraints I went for the simpler option of adding a generated
EXTERNAL_DEPENDENCIESfile. Patches for including the source are welcome.
Fair enough. It's straightforward by hand, and I only really package twice a year.
What about the qemu-system-arm build break I also mentioned? That's currently blocking my packaging.
Thanks,
:-Dustin
Quoted 4 lines · Dustin Kirkland
What about the qemu-system-arm build break I also mentioned? That's currently blocking my packaging.
I'm looking into it, though of course patches are welcome as usual.
Signature · 1 line
error compiling committee.c: too many arguments to function
Hi,
after upgrading from qemu-kvm-0.11.1 to qemu-kvm-0.12.0-rc2 I noticed two immediate problems on two different hosts:
1.) The e1000 driver doesn't work anymore. The Guest OS detects it (tested with Ubuntu Karmic 64-Bit and Windows 7 64 Bit), but it doesn't work. DHCP doesn't work, if you assign manually an IP address, you can ping this locally (inside the guest), but nothing else. Switching to virtio and my network is ok.
2.) If you specify an USB device at the command line like -usbdevice host:0421:00ab and the device is not available (not plugged-in) when you start the guest, qemu segfaults.
I am running kvm-kmod-2.6.32.
Both hosts are Intel machines, one is running a 64-Bit Ubuntu Karmic, the other is running Fedora 12.
If you need further information, I am happy to provide. Please let me know.
Thanks,
Ingmar
Quoted 15 lines · Avi Kivity
qemu-kvm-0.12.0-rc2 is now available. This release is is based on the upstream qemu 0.12.0-rc2, plus kvm-specific enhancements. Please see the original qemu 0.12.0-rc2 release announcement for details.
This release can be used with the kvm kernel modules provided by your distribution kernel, or by the modules in the kvm-kmod package, such as kvm-kmod-2.6.32.
Please give test this release out so we can enjoy a stable 0.12.0 final release.
[1] http://www.mail-archive.com/[email protected]/msg20151.html
(copying qemu-devel)
Quoted 44 lines · Ingmar Schraub
Hi,
after upgrading from qemu-kvm-0.11.1 to qemu-kvm-0.12.0-rc2 I noticed two immediate problems on two different hosts:
1.) The e1000 driver doesn't work anymore. The Guest OS detects it (tested with Ubuntu Karmic 64-Bit and Windows 7 64 Bit), but it doesn't work. DHCP doesn't work, if you assign manually an IP address, you can ping this locally (inside the guest), but nothing else. Switching to virtio and my network is ok.
2.) If you specify an USB device at the command line like -usbdevice host:0421:00ab and the device is not available (not plugged-in) when you start the guest, qemu segfaults.
I am running kvm-kmod-2.6.32.
Both hosts are Intel machines, one is running a 64-Bit Ubuntu Karmic, the other is running Fedora 12.
If you need further information, I am happy to provide. Please let me know.
Thanks,
Ingmar
Quoted 16 lines · Avi Kivity
qemu-kvm-0.12.0-rc2 is now available. This release is is based on the upstream qemu 0.12.0-rc2, plus kvm-specific enhancements. Please see the original qemu 0.12.0-rc2 release announcement for details.
This release can be used with the kvm kernel modules provided by your distribution kernel, or by the modules in the kvm-kmod package, such as kvm-kmod-2.6.32.
Please give test this release out so we can enjoy a stable 0.12.0 final release.
[1] http://www.mail-archive.com/[email protected]/msg20151.html
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 1 line · Ingmar Schraub
Hi,
Hi, Ingmar.
Quoted 8 lines
after upgrading from qemu-kvm-0.11.1 to qemu-kvm-0.12.0-rc2 I noticed two immediate problems on two different hosts:
1.) The e1000 driver doesn't work anymore. The Guest OS detects it (tested with Ubuntu Karmic 64-Bit and Windows 7 64 Bit), but it doesn't work. DHCP doesn't work, if you assign manually an IP address, you can ping this locally (inside the guest), but nothing else. Switching to virtio and my network is ok.
It seems to be the same problem that I have with OpenBSD 4.5 [1]. I did not test with Virtio because I don't know if OBSD kernel supports it. Testing with the default network interface and the same kernel compiled (with disabled mpbios device) I have the same problem.
When I was using KVM-62, I was using the ne2k_pci driver with stock kernel and this configuration worked without problems. But this configuration stopped working with KVM-88 and, under these circumstances, mbios disabled and e1000 gave good results for me.
Backing to use the ne2k_pci driver with mpbios disabled, the network is reachable again. I will to try with stock kernel and I will comment the results.
Quoted 3 lines
[...]
I am running kvm-kmod-2.6.32.
In my case it is Linux 2.6.32 with qemu-kvm-0.12.0-rc2.
Quoted 2 lines
Both hosts are Intel machines, one is running a 64-Bit Ubuntu Karmic, the other is running Fedora 12.
In this case I'm using Ubuntu Hardy Heron amd64 on the host and OpenBSD 4.5 i386 on guest.
Regards,
Daniel
[1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/44036
Signature · 2 lines
Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598
Quoted 11 lines · Ingmar Schraub
Hi,
after upgrading from qemu-kvm-0.11.1 to qemu-kvm-0.12.0-rc2 I noticed two immediate problems on two different hosts:
1.) The e1000 driver doesn't work anymore. The Guest OS detects it (tested with Ubuntu Karmic 64-Bit and Windows 7 64 Bit), but it doesn't work. DHCP doesn't work, if you assign manually an IP address, you can ping this locally (inside the guest), but nothing else. Switching to virtio and my network is ok.
This has been fixed but it was after -rc2 was tagged.
Quoted 4 lines
2.) If you specify an USB device at the command line like -usbdevice host:0421:00ab and the device is not available (not plugged-in) when you start the guest, qemu segfaults.
Haven't heard this one yet. I'm assuming it's a qdev interaction.
Regards,
Anthony Liguori
Quoted 6 lines
Quoted 4 lines
2.) If you specify an USB device at the command line like -usbdevice host:0421:00ab and the device is not available (not plugged-in) when you start the guest, qemu segfaults.
Haven't heard this one yet. I'm assuming it's a qdev interaction.
No. It is monitor_printf(NULL, ...
Patch adding checks to usb-linux.c is on the qemu-devel list already.
I've seen someone posted another patch which makes monitor_printf not barf on mon == NULL, which would fix the segfault too.
cheers,
Gerd
Quoted 5 lines · On Tue, 15 Dec 2009 15:41:33 +0100 Gerd Hoffmann <[email protected]> wrote:
Quoted 5 lines
Quoted 4 lines
2.) If you specify an USB device at the command line like -usbdevice host:0421:00ab and the device is not available (not plugged-in) when you start the guest, qemu segfaults.
Quoted 8 lines
Quoted 1 line
Haven't heard this one yet. I'm assuming it's a qdev interaction.
No. It is monitor_printf(NULL, ...
Patch adding checks to
usb-linux.cis on the qemu-devel list already.I've seen someone posted another patch which makes
monitor_printfnot barf on mon == NULL, which would fix the segfault too.
It's me:
http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg01602.html
Fix compile without eventfd.
--- compatfd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
compatfd.c +1 -1
@@ -118,9 +118,9 @@int qemu_eventfd (int *fds) { -#if defined(CONFIG_EVENTFD )int ret; +#if defined(CONFIG_EVENTFD ) ret =syscall (SYS_eventfd,0 );if (ret >=0 ) { fds[0 ] = ret;
Quoted 1 line · Bernhard Held
Fix compile without eventfd.
Thanks, but already applied an identical patch from Christ Wright.
Signature · 1 line
error compiling committee.c: too many arguments to function