Re: [Qemu-devel] [PATCH] e1000: Discard oversized packets based on SBP|LPE
18.12.2012 21:34, Michael Contreras пишет: On Tue, Dec 18, 2012 at 05:49:16PM +0100, Stefan Hajnoczi wrote: On Tue, Dec 18, 2012 at 5:20 PM, Michael Tokarev wrote: On 18.12.2012 17:44, Stefan Hajnoczi wrote: On Wed, Dec 05, 2012 at 01:31:30PM -0500, Michael Contreras wrote: Discard packets longer than 16384 when !SBP to match the hardware behavior. Signed-off-by: Michael Contreras --- hw/e1000.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) It looks like another very good candidate for -stable (up to quite some releases of qemu ago), together with the previous similar patch. Yes, it's good for -stable. Stefan Thanks guys. Any update on the CVE number? Seems the KVM qemu git tree still has this vulnerability. Xen has the fix in their qemu unstable git mirror, but hasn't applied it yet either. This issue has been assigned CVE-2012-6075. qemu-kvm does not exist anymore, it is just an internal development tree for qemu, sort of like a subsystem tree - there will be no more qemu-kvm releases. So we care only about qemu (main, older versions, incl. 0.12 and 0.15, are also affected), old qemu-kvm, and xen. CC'ing afaerber for 0.15. Thank you! /mjt
[Qemu-devel] [PATCH v3] disallow -daemonize usage of stdio (curses display, -nographic, -serial stdio etc)
Curses display requires stdin/out to stay on the terminal,
so -daemonize makes no sense in this case. Instead of
leaving display uninitialized like is done since 995ee2bf469de6bb,
explicitly detect this case earlier and error out.
-nographic can actually be used with -daemonize, by redirecting
everything to a null device, but the problem is that according
to documentation and historical behavour, -nographic redirects
guest ports to stdin/out, which, again, makes no sense in case
of -daemonize. Since -nographic is a legacy option, don't bother
fixing this case (to allow -nographic and -daemonize by redirecting
guest ports to null instead of stdin/out in this case), but disallow
it completely instead, to stop garbling host terminal.
If no display display needed and user wants to use -nographic,
the right way to go is to use
-serial null -parallel null -monitor none -display none -vga none
instead of -nographic.
Also prevent the same issue -- it was possible to get garbled
host tty after
-nographic -daemonize
and it is still possible to have it by using
-serial stdio -daemonize
Fix this by disallowing opening stdio chardev when -daemonize
is specified.
Signed-off-by: Michael Tokarev
---
qemu-char.c |4
vl.c| 28 +---
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index c6382a9..331ad5c 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -772,6 +772,10 @@ static CharDriverState *qemu_chr_open_stdio(QemuOpts *opts)
if (stdio_nb_clients >= STDIO_MAX_CLIENTS) {
return NULL;
}
+if (is_daemonized()) {
+error_report("cannot use stdio with -daemonize");
+return NULL;
+}
if (stdio_nb_clients == 0) {
old_fd0_flags = fcntl(0, F_GETFL);
tcgetattr (0, &oldtty);
diff --git a/vl.c b/vl.c
index e6a8d89..f056c95 100644
--- a/vl.c
+++ b/vl.c
@@ -3637,6 +3637,30 @@ int main(int argc, char **argv, char **envp)
default_sdcard = 0;
}
+if (is_daemonized()) {
+/* According to documentation and historically, -nographic redirects
+ * serial port, parallel port and monitor to stdio, which does not work
+ * with -daemonize. We can redirect these to null instead, but since
+ * -nographic is legacy, let's just error out.
+ * We disallow -nographic only if all other ports are not redirected
+ * explicitly, to not break existing legacy setups which uses
+ * -nographic _and_ redirects all ports explicitly - this is valid
+ * usage, -nographic is just a no-op in this case.
+ */
+if (display_type == DT_NOGRAPHIC
+&& (default_parallel || default_serial
+|| default_monitor || default_virtcon)) {
+fprintf(stderr, "-nographic can not be used with -daemonize\n");
+exit(1);
+}
+#ifdef CONFIG_CURSES
+if (display_type == DT_CURSES) {
+fprintf(stderr, "curses display can not be used with
-daemonize\n");
+exit(1);
+}
+#endif
+}
+
if (display_type == DT_NOGRAPHIC) {
if (default_parallel)
add_device_config(DEV_PARALLEL, "null");
@@ -3903,9 +3927,7 @@ int main(int argc, char **argv, char **envp)
break;
#if defined(CONFIG_CURSES)
case DT_CURSES:
-if (!is_daemonized()) {
-curses_display_init(ds, full_screen);
-}
+curses_display_init(ds, full_screen);
break;
#endif
#if defined(CONFIG_SDL)
--
1.7.10.4
Re: [Qemu-devel] [PATCH 6/6] usb-tablet: Allow connecting to ehci
Hi, On 12/26/2012 01:07 PM, Erik Rull wrote: Hi Gerd, hi Hans, is my assumption correct that if I check out and compile this version from GIT master that the usb-tablet device is automatically routed to ehci without changing anything else in the qemu call arguments? (And the performance enhancement takes place automatically) If not - what has to be changed to get it working? That depends, if you specify a machine model, you need to change it to pc-1.4, if you don't specify a machine model you will get the change automatically, as 1.4 is the new default machine model. Regards, Hans
[Qemu-devel] [Bug 1094564] [NEW] images used as scsi disks not readable (qemu-system-arm, macos 10.8)
Public bug reported: Using a arm1176 kernel and the raspbian image (10-28 or 12-16) as my disk, I get as far as mounting root and then get SCSI errors with 1.3.0 and the current origin/master. git bisect says the issue is commit f563a5d7a820424756f358e747238f03e866838a Merge: a273652 aee0bf7 Author: Paolo Bonzini Date: Wed Oct 31 10:42:51 2012 +0100 Merge remote-tracking branch 'origin/master' into threadpool Signed-off-by: Paolo Bonzini I am using: qemu-system-arm -no-reboot -M versatilepb -cpu arm1176 -m 256 -hda 2012-12-16-wheezy-raspbian.img -kernel kernel-qemu -append "root=/dev/sda2 rootfstype=ext4 elevator=deadline rootwait panic=1" -serial stdio -usbdevice tablet -net nic -net user,hostfwd=tcp::40022-:22 Configured on MacOS 10.8.2 with current Xcode and MacPorts installed, thus: CPATH=/opt/local/include CFLAGS="-pipe -O2 -arch x86_64" CPPFLAGS="-I/opt/local/include" CXXFLAGS="-pipe -O2 -arch x86_64" LIBRARY_PATH="/opt/local/lib" MACOSX_DEPLOYMENT_TARGET="10.8" CXX="/usr/bin/clang++" LDFLAGS="-L/opt/local/lib -arch x86_64" OBJC=/usr/bin/clang FCFLAGS="-pipe -O2 -m64" INSTALL="/usr/bin/install -c" OBJCFLAGS="-pipe -O2 -arch x86_64" CC="/usr/bin/clang" ./configure --prefix=/opt/local --cpu=x86_64 --cc=/usr/bin/clang --objcc=/usr/bin/clang --host-cc=/usr/bin/clang --python=/opt/local/bin/python2.7 --target-list=arm-softmmu ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1094564 Title: images used as scsi disks not readable (qemu-system-arm, macos 10.8) Status in QEMU: New Bug description: Using a arm1176 kernel and the raspbian image (10-28 or 12-16) as my disk, I get as far as mounting root and then get SCSI errors with 1.3.0 and the current origin/master. git bisect says the issue is commit f563a5d7a820424756f358e747238f03e866838a Merge: a273652 aee0bf7 Author: Paolo Bonzini Date: Wed Oct 31 10:42:51 2012 +0100 Merge remote-tracking branch 'origin/master' into threadpool Signed-off-by: Paolo Bonzini I am using: qemu-system-arm -no-reboot -M versatilepb -cpu arm1176 -m 256 -hda 2012-12-16-wheezy-raspbian.img -kernel kernel-qemu -append "root=/dev/sda2 rootfstype=ext4 elevator=deadline rootwait panic=1" -serial stdio -usbdevice tablet -net nic -net user,hostfwd=tcp::40022-:22 Configured on MacOS 10.8.2 with current Xcode and MacPorts installed, thus: CPATH=/opt/local/include CFLAGS="-pipe -O2 -arch x86_64" CPPFLAGS="-I/opt/local/include" CXXFLAGS="-pipe -O2 -arch x86_64" LIBRARY_PATH="/opt/local/lib" MACOSX_DEPLOYMENT_TARGET="10.8" CXX="/usr/bin/clang++" LDFLAGS="-L/opt/local/lib -arch x86_64" OBJC=/usr/bin/clang FCFLAGS="-pipe -O2 -m64" INSTALL="/usr/bin/install -c" OBJCFLAGS="-pipe -O2 -arch x86_64" CC="/usr/bin/clang" ./configure --prefix=/opt/local --cpu=x86_64 --cc=/usr/bin/clang --objcc=/usr/bin/clang --host-cc=/usr/bin/clang --python=/opt/local/bin/python2.7 --target-list=arm-softmmu To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1094564/+subscriptions
Re: [Qemu-devel] [PATCH 6/6] usb-tablet: Allow connecting to ehci
Hi Hans, Hans de Goede wrote: Hi, On 12/26/2012 01:07 PM, Erik Rull wrote: Hi Gerd, hi Hans, is my assumption correct that if I check out and compile this version from GIT master that the usb-tablet device is automatically routed to ehci without changing anything else in the qemu call arguments? (And the performance enhancement takes place automatically) If not - what has to be changed to get it working? That depends, if you specify a machine model, you need to change it to pc-1.4, if you don't specify a machine model you will get the change automatically, as 1.4 is the new default machine model. Regards, Hans Thanks. QEMU shows version 1.3.50 at the moment (from git), is the 1.4 model internally already active there? Best regards, Erik
[Qemu-devel] [PATCH] virtio-pci: replace byte swap hack
Remove byte swaps by declaring the config space
as native endian.
Signed-off-by: Blue Swirl
---
exec.c | 18 --
hw/virtio-pci.c | 17 +
2 files changed, 1 insertions(+), 34 deletions(-)
diff --git a/exec.c b/exec.c
index a6923ad..140eb56 100644
--- a/exec.c
+++ b/exec.c
@@ -2587,24 +2587,6 @@ int cpu_memory_rw_debug(CPUArchState *env, target_ulong
addr,
}
#endif
-#if !defined(CONFIG_USER_ONLY)
-
-/*
- * A helper function for the _utterly broken_ virtio device model to find out
if
- * it's running on a big endian machine. Don't do this at home kids!
- */
-bool virtio_is_big_endian(void);
-bool virtio_is_big_endian(void)
-{
-#if defined(TARGET_WORDS_BIGENDIAN)
-return true;
-#else
-return false;
-#endif
-}
-
-#endif
-
#ifndef CONFIG_USER_ONLY
bool cpu_physical_memory_is_io(hwaddr phys_addr)
{
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index d2d2454..df78a3b 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -92,9 +92,6 @@
*/
#define wmb() do { } while (0)
-/* HACK for virtio to determine if it's running a big endian guest */
-bool virtio_is_big_endian(void);
-
/* virtio device */
static void virtio_pci_notify(void *opaque, uint16_t vector)
@@ -390,15 +387,9 @@ static uint64_t virtio_pci_config_read(void *opaque,
hwaddr addr,
break;
case 2:
val = virtio_config_readw(proxy->vdev, addr);
-if (virtio_is_big_endian()) {
-val = bswap16(val);
-}
break;
case 4:
val = virtio_config_readl(proxy->vdev, addr);
-if (virtio_is_big_endian()) {
-val = bswap32(val);
-}
break;
}
return val;
@@ -423,15 +414,9 @@ static void virtio_pci_config_write(void *opaque, hwaddr
addr,
virtio_config_writeb(proxy->vdev, addr, val);
break;
case 2:
-if (virtio_is_big_endian()) {
-val = bswap16(val);
-}
virtio_config_writew(proxy->vdev, addr, val);
break;
case 4:
-if (virtio_is_big_endian()) {
-val = bswap32(val);
-}
virtio_config_writel(proxy->vdev, addr, val);
break;
}
@@ -444,7 +429,7 @@ static const MemoryRegionOps virtio_pci_config_ops = {
.min_access_size = 1,
.max_access_size = 4,
},
-.endianness = DEVICE_LITTLE_ENDIAN,
+.endianness = DEVICE_NATIVE_ENDIAN,
};
static void virtio_write_config(PCIDevice *pci_dev, uint32_t address,
--
1.7.2.5
[Qemu-devel] [Bug 918791] Re: qemu-kvm dies when using vmvga driver and unity in the guest
I've checked Serge's fix and it does fix crashes. Now I've pulled latest qemu-kvm git master, and it appears that this patch isn't there... I still have to apply it on top of latest git to avoid crashes. What progress is here? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/918791 Title: qemu-kvm dies when using vmvga driver and unity in the guest Status in QEMU: New Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “xserver-xorg-video-vmware” package in Ubuntu: Invalid Status in “qemu-kvm” source package in Oneiric: Fix Committed Status in “xserver-xorg-video-vmware” source package in Oneiric: Invalid Status in “qemu-kvm” source package in Precise: Fix Released Status in “xserver-xorg-video-vmware” source package in Precise: Invalid Bug description: = SRU Justification: 1. impact: kvm crashes 2. Development fix: don't allow attempts to set_bit to negative offsets 3. Stable fix: same as development fix 4. Test case (see below) 5. Regression potential: if the patch is wrong, graphics for vmware vga over vnc could get messed up = 12.04's qemu-kvm has been unstable for me and Marc Deslauriers and I figured out it has something to do with the interaction of qemu-kvm, unity and the vmvga driver. This is a regression over qemu-kvm in 11.10. TEST CASE: 1. start a VM that uses unity (eg, 11.04, 11.10 or 12.04). My tests use unity-2d on an amd64 host and amd64 guests 2. on 11.04 and 11.10, open empathy via the messaging indicator and click 'Chat'. On 12.04, open empathy via the messaging indicator and click 'Chat', close the empathy wizard, move the empathy window over the unity luancher (so it autohides), then do 'ctrl+alt+t' to open a terminal When the launcher tries to auto(un)hide, qemu-kvm dies with this: [10574.958149] do_general_protection: 132 callbacks suppressed [10574.958154] kvm[13192] general protection ip:7fab9680ea0f sp:74440148 error:0 in qemu-system-x86_64[7fab966c4000+2c9000] Relevant libvirt xml: If I change to using 'cirrus', then qemu-kvm no longer crashes. Eg: The workaround is therefore to use the cirrus driver instead of vmvga, however being able to kill qemu-kvm in this manner is not ideal. Also, unfortunately unity-2d does not run with with cirrus driver under 11.04, so the security and SRU teams are unable to properly test updates in GUI applications under unity when using the current 12.04 qemu-kvm. I tried to report this via apport, but apport complained about a CRC error, so I could not. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/918791/+subscriptions
[Qemu-devel] gen_icount_start
Hi , I am trying to understand how to count the number of instructions executed in the guest and came across the gen_icount_start and gen_icount_end functions. What I understand is that in gen_icount_start 'icount_arg' keeps a pointer to gen_opparam_ptr which is used in gen_icount_end to patch up the value . I however didnt understand what the 'horrid hack' is about. Can any one give me some idea on this ? Thanks !
Re: [Qemu-devel] gen_icount_start
On 30 December 2012 23:14, biswaranjan panda wrote: > What I understand is that in gen_icount_start 'icount_arg' keeps a pointer > to gen_opparam_ptr which is used in gen_icount_end to patch up the value . I > however didnt understand what the 'horrid hack' is about. Can any one give > me some idea on this ? My guess is that it's a hack because it's a layering violation. Functions that generate TCG (intermediate representation) should do it by calling the tcg_ functions, and the data structures and variables like gen_opparam_ptr should be internal to the TCG layer. However here we rely on knowing implementation details of how the TCG layer actually writes out the ops and parameters when you call tcg_gen_subi_i32(). A clean design would make the TCG layer provide some kind of API for writing out code and then fixing up the values afterwards, but on the other hand if we only have one use case... -- PMM
[Qemu-devel] [Bug 1094786] [NEW] static build with curses fails if requires -ltinfo
Public bug reported: On my system (amd64 Debian wheezy/sid) static ncurses build requires -ltinfo: $ pkg-config --libs --static ncurses -lncurses -ltinfo $ ../../configure --enable-curses --static # Actually this fails on line if compile_prog "" "$curses_lib" ; then # with ERROR ERROR: User requested feature curses ERROR: configure was not able to find it ERROR # but if we add -ltinfo to this line check succeds ... static build yes ... $ make ... ... CCi386-softmmu/hw/i386/../kvm/pci-assign.o LINK i386-softmmu/qemu-system-i386 ../os-posix.o: In function `change_process_uid': /home/vadim/soft/qemu/os-posix.c:205: warning: Using 'initgroups' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking # and many alike warnings ... ../ui/curses.o: In function `curses_cursor_position': /home/vadim/soft/qemu/ui/curses.c:137: undefined reference to `COLS' /home/vadim/soft/qemu/ui/curses.c:137: undefined reference to `LINES' /home/vadim/soft/qemu/ui/curses.c:138: undefined reference to `stdscr' /home/vadim/soft/qemu/ui/curses.c:139: undefined reference to `curs_set' ../ui/curses.o: In function `curses_calc_pad': /home/vadim/soft/qemu/ui/curses.c:68: undefined reference to `stdscr' /home/vadim/soft/qemu/ui/curses.c:69: undefined reference to `stdscr' ... and so on I tried to build the very minimal static qemu executable. Actual configure line I tried first was ../../configure --target-list=i386-softmmu --disable-sdl --disable-virtfs --disable-vnc --disable-xen --disable-brlapi --disable-bluez --disable-slirp --disable-kvm --disable-user --disable-vde --disable-vhost-net --disable-spice --disable-libiscsi --disable-smartcard --disable-usb-redir --disable-guest-agent --audio-drv-list= --audio-card-list= --enable-curses --static and the errors was the same. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1094786 Title: static build with curses fails if requires -ltinfo Status in QEMU: New Bug description: On my system (amd64 Debian wheezy/sid) static ncurses build requires -ltinfo: $ pkg-config --libs --static ncurses -lncurses -ltinfo $ ../../configure --enable-curses --static # Actually this fails on line if compile_prog "" "$curses_lib" ; then # with ERROR ERROR: User requested feature curses ERROR: configure was not able to find it ERROR # but if we add -ltinfo to this line check succeds ... static build yes ... $ make ... ... CCi386-softmmu/hw/i386/../kvm/pci-assign.o LINK i386-softmmu/qemu-system-i386 ../os-posix.o: In function `change_process_uid': /home/vadim/soft/qemu/os-posix.c:205: warning: Using 'initgroups' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking # and many alike warnings ... ../ui/curses.o: In function `curses_cursor_position': /home/vadim/soft/qemu/ui/curses.c:137: undefined reference to `COLS' /home/vadim/soft/qemu/ui/curses.c:137: undefined reference to `LINES' /home/vadim/soft/qemu/ui/curses.c:138: undefined reference to `stdscr' /home/vadim/soft/qemu/ui/curses.c:139: undefined reference to `curs_set' ../ui/curses.o: In function `curses_calc_pad': /home/vadim/soft/qemu/ui/curses.c:68: undefined reference to `stdscr' /home/vadim/soft/qemu/ui/curses.c:69: undefined reference to `stdscr' ... and so on I tried to build the very minimal static qemu executable. Actual configure line I tried first was ../../configure --target-list=i386-softmmu --disable-sdl --disable-virtfs --disable-vnc --disable-xen --disable-brlapi --disable-bluez --disable-slirp --disable-kvm --disable-user --disable-vde --disable-vhost-net --disable-spice --disable-libiscsi --disable-smartcard --disable-usb-redir --disable-guest-agent --audio-drv-list= --audio-card-list= --enable-curses --static and the errors was the same. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1094786/+subscriptions
