qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] a8bba0: virtio: Tell the user what went wrong


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] a8bba0: virtio: Tell the user what went wrong when event_n...
Date: Mon, 12 Sep 2016 05:00:04 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: a8bba0ada41b228e4dd5113a02f20bbc0f5d6f0a
      
https://github.com/qemu/qemu/commit/a8bba0ada41b228e4dd5113a02f20bbc0f5d6f0a
  Author: Thomas Huth <address@hidden>
  Date:   2016-09-09 (Fri, 09 Sep 2016)

  Changed paths:
    M hw/virtio/virtio-bus.c

  Log Message:
  -----------
  virtio: Tell the user what went wrong when event_notifier_init failed

event_notifier_init() can fail in real life, for example when there
are not enough open file handles available (EMFILE) when using a lot
of devices. So instead of leaving the average user with a cryptic
error number only, print out a proper error message with strerror()
instead, so that the user has a better way to figure out what is
going on and that using "ulimit -n" might help here for example.

Signed-off-by: Thomas Huth <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: e3aab6c7f37a288452218ebdbfe39db41382495d
      
https://github.com/qemu/qemu/commit/e3aab6c7f37a288452218ebdbfe39db41382495d
  Author: Michael S. Tsirkin <address@hidden>
  Date:   2016-09-09 (Fri, 09 Sep 2016)

  Changed paths:
    M hw/virtio/virtio-pci.c

  Log Message:
  -----------
  virtio-pci: use size from correct structure

PIO MR registration should use size from the correct notify struct.
Doesn't affect any visible behaviour because the field values are the
same (both are 4).

Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: a4d3c8347627203d8c17172a3f4d9c4f39fee6e2
      
https://github.com/qemu/qemu/commit/a4d3c8347627203d8c17172a3f4d9c4f39fee6e2
  Author: Longpeng(Mike) <address@hidden>
  Date:   2016-09-09 (Fri, 09 Sep 2016)

  Changed paths:
    M hw/i386/pc_piix.c
    M hw/i386/pc_q35.c
    M include/hw/i386/pc.h

  Log Message:
  -----------
  pc: Add 2.8 machine

This will used by the next patch.

Signed-off-by: Longpeng(Mike) <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 14c985cffa6cb177fc01a163d8bcf227c104718c
      
https://github.com/qemu/qemu/commit/14c985cffa6cb177fc01a163d8bcf227c104718c
  Author: Longpeng(Mike) <address@hidden>
  Date:   2016-09-09 (Fri, 09 Sep 2016)

  Changed paths:
    M include/hw/i386/pc.h
    M target-i386/cpu.c
    M target-i386/cpu.h

  Log Message:
  -----------
  target-i386: present virtual L3 cache info for vcpus

Some software algorithms are based on the hardware's cache info, for example,
for x86 linux kernel, when cpu1 want to wakeup a task on cpu2, cpu1 will trigger
a resched IPI and told cpu2 to do the wakeup if they don't share low level
cache. Oppositely, cpu1 will access cpu2's runqueue directly if they share llc.
The relevant linux-kernel code as bellow:

        static void ttwu_queue(struct task_struct *p, int cpu)
        {
                struct rq *rq = cpu_rq(cpu);
                ......
                if (... && !cpus_share_cache(smp_processor_id(), cpu)) {
                        ......
                        ttwu_queue_remote(p, cpu); /* will trigger RES IPI */
                        return;
                }
                ......
                ttwu_do_activate(rq, p, 0); /* access target's rq directly */
                ......
        }

In real hardware, the cpus on the same socket share L3 cache, so one won't
trigger a resched IPIs when wakeup a task on others. But QEMU doesn't present a
virtual L3 cache info for VM, then the linux guest will trigger lots of RES IPIs
under some workloads even if the virtual cpus belongs to the same virtual 
socket.

For KVM, there will be lots of vmexit due to guest send IPIs.
The workload is a SAP HANA's testsuite, we run it one round(about 40 minuates)
and observe the (Suse11sp3)Guest's amounts of RES IPIs which triggering during
the period:
  No-L3           With-L3(applied this patch)
cpu0:   363890          44582
cpu1:   373405          43109
cpu2:   340783          43797
cpu3:   333854          43409
cpu4:   327170          40038
cpu5:   325491          39922
cpu6:   319129          42391
cpu7:   306480          41035
cpu8:   161139          32188
cpu9:   164649          31024
cpu10:  149823          30398
cpu11:  149823          32455
cpu12:  164830          35143
cpu13:  172269          35805
cpu14:  179979          33898
cpu15:  194505          32754
avg:    268963.6        40129.8

The VM's topology is "1*socket 8*cores 2*threads".
After present virtual L3 cache info for VM, the amounts of RES IPIs in guest
reduce 85%.

For KVM, vcpus send IPIs will cause vmexit which is expensive, so it can cause
severe performance degradation. We had tested the overall system performance if
vcpus actually run on sparate physical socket. With L3 cache, the performance
improves 7.2%~33.1%(avg:15.7%).

Signed-off-by: Longpeng(Mike) <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: d9997d89a4a09a330a056929d06d4b7b0b7a8239
      
https://github.com/qemu/qemu/commit/d9997d89a4a09a330a056929d06d4b7b0b7a8239
  Author: Marcel Apfelbaum <address@hidden>
  Date:   2016-09-09 (Fri, 09 Sep 2016)

  Changed paths:
    M hw/virtio/virtio-pci.c
    M hw/virtio/virtio-pci.h
    M include/hw/compat.h

  Log Message:
  -----------
  virtio-pci: reduce modern_mem_bar size

Currently each VQ Notification Virtio Capability is allocated
on a different page. The idea is to enable split drivers within
guests, however there are no known plans to do that.
The allocation will result in a 8MB BAR, more than various
guest firmwares pre-allocates for PCI Bridges hotplug process.

Reserve 4 bytes per VQ by default and add a new parameter
"page-per-vq" to be used with split drivers.

Signed-off-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 4b7f91ed0270a371e1933efa21ba600b6da23ab9
      
https://github.com/qemu/qemu/commit/4b7f91ed0270a371e1933efa21ba600b6da23ab9
  Author: Stefan Hajnoczi <address@hidden>
  Date:   2016-09-09 (Fri, 09 Sep 2016)

  Changed paths:
    M hw/virtio/virtio.c

  Log Message:
  -----------
  virtio: zero vq->inuse in virtio_reset()

vq->inuse must be zeroed upon device reset like most other virtqueue
fields.

In theory, virtio_reset() just needs assert(vq->inuse == 0) since
devices must clean up in-flight requests during reset (requests cannot
not be leaked!).

In practice, it is difficult to achieve vq->inuse == 0 across reset
because balloon, blk, 9p, etc implement various different strategies for
cleaning up requests.  Most devices call g_free(elem) directly without
telling virtio.c that the VirtQueueElement is cleaned up.  Therefore
vq->inuse is not decremented during reset.

This patch zeroes vq->inuse and trusts that devices are not leaking
VirtQueueElements across reset.

I will send a follow-up series that refactors request life-cycle across
all devices and converts vq->inuse = 0 into assert(vq->inuse == 0) but
this more invasive approach is not appropriate for stable trees.

Signed-off-by: Stefan Hajnoczi <address@hidden>
Cc: qemu-stable <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Ladi Prosek <address@hidden>


  Commit: 104e70cae78bd4afd95d948c6aff188f10508a9c
      
https://github.com/qemu/qemu/commit/104e70cae78bd4afd95d948c6aff188f10508a9c
  Author: Ladi Prosek <address@hidden>
  Date:   2016-09-09 (Fri, 09 Sep 2016)

  Changed paths:
    M hw/virtio/virtio-balloon.c

  Log Message:
  -----------
  virtio-balloon: discard virtqueue element on reset

The one pending element is being freed but not discarded on device
reset, which causes svq->inuse to creep up, eventually hitting the
"Virtqueue size exceeded" error.

Properly discarding the element on device reset makes sure that its
buffers are unmapped and the inuse counter stays balanced.

Cc: Michael S. Tsirkin <address@hidden>
Cc: Roman Kagan <address@hidden>
Cc: Stefan Hajnoczi <address@hidden>
Signed-off-by: Ladi Prosek <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 297a75e6c55d91db2704a3d6e4029d99c7df51fd
      
https://github.com/qemu/qemu/commit/297a75e6c55d91db2704a3d6e4029d99c7df51fd
  Author: Stefan Hajnoczi <address@hidden>
  Date:   2016-09-09 (Fri, 09 Sep 2016)

  Changed paths:
    M hw/virtio/virtio.c
    M include/hw/virtio/virtio.h

  Log Message:
  -----------
  virtio: add virtqueue_rewind()

virtqueue_discard() requires a VirtQueueElement but virtio-balloon does
not migrate its in-use element.  Introduce a new function that is
similar to virtqueue_discard() but doesn't require a VirtQueueElement.

This will allow virtio-balloon to access element again after migration
with the usual proviso that the guest may have modified the vring since
last time.

Cc: Michael S. Tsirkin <address@hidden>
Cc: Roman Kagan <address@hidden>
Cc: Stefan Hajnoczi <address@hidden>
Signed-off-by: Ladi Prosek <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 4a1e48becab81020adfb74b22c76a595f2d02a01
      
https://github.com/qemu/qemu/commit/4a1e48becab81020adfb74b22c76a595f2d02a01
  Author: Ladi Prosek <address@hidden>
  Date:   2016-09-09 (Fri, 09 Sep 2016)

  Changed paths:
    M hw/virtio/virtio-balloon.c

  Log Message:
  -----------
  virtio-balloon: fix stats vq migration

The statistics virtqueue is not migrated properly because virtio-balloon
does not include s->stats_vq_elem in the migration stream.

After migration the statistics virtqueue hangs because the host never
completes the last element (s->stats_vq_elem is NULL on the destination
QEMU).  Therefore the guest never submits new elements and the virtqueue
is hung.

Instead of changing the migration stream format in an incompatible way,
detect the migration case and rewind the virtqueue so the last element
can be completed.

Cc: Michael S. Tsirkin <address@hidden>
Cc: Roman Kagan <address@hidden>
Cc: Stefan Hajnoczi <address@hidden>
Suggested-by: Roman Kagan <address@hidden>
Signed-off-by: Ladi Prosek <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 3eff376977c457475272a34d243dac6af7cd6a47
      
https://github.com/qemu/qemu/commit/3eff376977c457475272a34d243dac6af7cd6a47
  Author: Greg Kurz <address@hidden>
  Date:   2016-09-09 (Fri, 09 Sep 2016)

  Changed paths:
    M hw/virtio/virtio-pci.c

  Log Message:
  -----------
  virtio-pci: error out when both legacy and modern modes are disabled

Without presuming if we got there because of a user mistake or some
more subtle bug in the tooling, it really does not make sense to
implement a non-functional device.

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 96a3d98d2cdbd897ff5ab33427aa4cfb94077665
      
https://github.com/qemu/qemu/commit/96a3d98d2cdbd897ff5ab33427aa4cfb94077665
  Author: Jason Wang <address@hidden>
  Date:   2016-09-09 (Fri, 09 Sep 2016)

  Changed paths:
    M hw/virtio/vhost.c

  Log Message:
  -----------
  vhost: don't set vring call if no vector

We used to set vring call fd unconditionally even if guest driver does
not use MSIX for this vritqueue at all. This will cause lots of
unnecessary userspace access and other checks for drivers does not use
interrupt at all (e.g virtio-net pmd). So check and clean vring call
fd if guest does not use any vector for this virtqueue at
all.

Perf diffs (on rx) shows lots of cpus wasted on vhost_signal() were saved:

#
    28.12%  -27.82%  [vhost]           [k] vhost_signal
    14.44%   -1.69%  [kernel.vmlinux]  [k] copy_user_generic_string
     7.05%   +1.53%  [kernel.vmlinux]  [k] __free_page_frag
     6.51%   +5.53%  [vhost]           [k] vhost_get_vq_desc
...

Pktgen tests shows 15.8% improvement on rx pps and 6.5% on tx pps.

Before: RX 2.08Mpps TX 1.35Mpps
After:  RX 2.41Mpps TX 1.44Mpps

Signed-off-by: Jason Wang <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 71d19fc51387ba599f6222057fd69c58b3c0ce7e
      
https://github.com/qemu/qemu/commit/71d19fc51387ba599f6222057fd69c58b3c0ce7e
  Author: Michael S. Tsirkin <address@hidden>
  Date:   2016-09-09 (Fri, 09 Sep 2016)

  Changed paths:
    M hw/virtio/virtio-pci.c

  Log Message:
  -----------
  virtio-pci: minor refactoring

!legacy && !modern is shorter than !(legacy || modern).
I also perfer this (less ()s) as a matter of taste.

Cc: Greg Kurz <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 947b205fdb46941453f0dc43316e13741d45834c
      
https://github.com/qemu/qemu/commit/947b205fdb46941453f0dc43316e13741d45834c
  Author: Marcel Apfelbaum <address@hidden>
  Date:   2016-09-10 (Sat, 10 Sep 2016)

  Changed paths:
    M tests/bios-tables-test.c

  Log Message:
  -----------
  tests/acpi: speedup acpi tests

Use kvm acceleration if available.
Disable kernel-irqchip and use qemu64 cpu
for both kvm and tcg cases.

Using kvm acceleration saves about a second
and disabling kernel-irqchip has no visible
performance impact.

Acked-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: fc0b9b0e1cbb49017ea882758634cf876be17bc3
      
https://github.com/qemu/qemu/commit/fc0b9b0e1cbb49017ea882758634cf876be17bc3
  Author: Stefan Hajnoczi <address@hidden>
  Date:   2016-09-10 (Sat, 10 Sep 2016)

  Changed paths:
    M configure
    M hw/s390x/virtio-ccw.c
    M hw/s390x/virtio-ccw.h
    M hw/virtio/Makefile.objs
    M hw/virtio/vhost-backend.c
    A hw/virtio/vhost-vsock.c
    M hw/virtio/virtio-pci.c
    M hw/virtio/virtio-pci.h
    M include/hw/pci/pci.h
    M include/hw/virtio/vhost-backend.h
    A include/hw/virtio/vhost-vsock.h

  Log Message:
  -----------
  vhost-vsock: add virtio sockets device

Implement the new virtio sockets device for host<->guest communication
using the Sockets API.  Most of the work is done in a vhost kernel
driver so that virtio-vsock can hook into the AF_VSOCK address family.
The QEMU vhost-vsock device handles configuration and live migration
while the rx/tx happens in the vhost_vsock.ko Linux kernel driver.

The vsock device must be given a CID (host-wide unique address):

  # qemu -device vhost-vsock-pci,id=vhost-vsock-pci0,guest-cid=3 ...

For more information see:
http://qemu-project.org/Features/VirtioVsock

[Endianness fixes and virtio-ccw support by Claudio Imbrenda
<address@hidden>]

Signed-off-by: Stefan Hajnoczi <address@hidden>
[mst: rebase to master]
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: c569c537e5c60ee9b9ed92b7a57d766c78b71318
      
https://github.com/qemu/qemu/commit/c569c537e5c60ee9b9ed92b7a57d766c78b71318
  Author: Peter Maydell <address@hidden>
  Date:   2016-09-12 (Mon, 12 Sep 2016)

  Changed paths:
    M configure
    M hw/i386/pc_piix.c
    M hw/i386/pc_q35.c
    M hw/s390x/virtio-ccw.c
    M hw/s390x/virtio-ccw.h
    M hw/virtio/Makefile.objs
    M hw/virtio/vhost-backend.c
    A hw/virtio/vhost-vsock.c
    M hw/virtio/vhost.c
    M hw/virtio/virtio-balloon.c
    M hw/virtio/virtio-bus.c
    M hw/virtio/virtio-pci.c
    M hw/virtio/virtio-pci.h
    M hw/virtio/virtio.c
    M include/hw/compat.h
    M include/hw/i386/pc.h
    M include/hw/pci/pci.h
    M include/hw/virtio/vhost-backend.h
    A include/hw/virtio/vhost-vsock.h
    M include/hw/virtio/virtio.h
    M target-i386/cpu.c
    M target-i386/cpu.h
    M tests/bios-tables-test.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging

virtio,vhost,pc: fixes and updates

balloon fixes wrt migration
virtio-vsock device support

Signed-off-by: Michael S. Tsirkin <address@hidden>

# gpg: Signature made Fri 09 Sep 2016 22:36:13 BST
# gpg:                using RSA key 0x281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <address@hidden>"
# gpg:                 aka "Michael S. Tsirkin <address@hidden>"
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17  0970 C350 3912 AFBE 8E67
#      Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA  8A0D 281F 0DB8 D28D 5469

* remotes/mst/tags/for_upstream:
  vhost-vsock: add virtio sockets device
  tests/acpi: speedup acpi tests
  virtio-pci: minor refactoring
  vhost: don't set vring call if no vector
  virtio-pci: error out when both legacy and modern modes are disabled
  virtio-balloon: fix stats vq migration
  virtio: add virtqueue_rewind()
  virtio-balloon: discard virtqueue element on reset
  virtio: zero vq->inuse in virtio_reset()
  virtio-pci: reduce modern_mem_bar size
  target-i386: present virtual L3 cache info for vcpus
  pc: Add 2.8 machine
  virtio-pci: use size from correct structure
  virtio: Tell the user what went wrong when event_notifier_init failed

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/c2a57aae9a1c...c569c537e5c6

reply via email to

[Prev in Thread] Current Thread [Next in Thread]