aboutsummaryrefslogtreecommitdiff
path: root/qapi
AgeCommit message (Collapse)AuthorFilesLines
2024-01-26monitor: only run coroutine commands in qemu_aio_contextStefan Hajnoczi1-1/+23
monitor_qmp_dispatcher_co() runs in the iohandler AioContext that is not polled during nested event loops. The coroutine currently reschedules itself in the main loop's qemu_aio_context AioContext, which is polled during nested event loops. One known problem is that QMP device-add calls drain_call_rcu(), which temporarily drops the BQL, leading to all sorts of havoc like other vCPU threads re-entering device emulation code while another vCPU thread is waiting in device emulation code with aio_poll(). Paolo Bonzini suggested running non-coroutine QMP handlers in the iohandler AioContext. This avoids trouble with nested event loops. His original idea was to move coroutine rescheduling to monitor_qmp_dispatch(), but I resorted to moving it to qmp_dispatch() because we don't know if the QMP handler needs to run in coroutine context in monitor_qmp_dispatch(). monitor_qmp_dispatch() would have been nicer since it's associated with the monitor implementation and not as general as qmp_dispatch(), which is also used by qemu-ga. A number of qemu-iotests need updated .out files because the order of QMP events vs QMP responses has changed. Solves Issue #1933. Cc: qemu-stable@nongnu.org Fixes: 7bed89958bfbf40df9ca681cefbdca63abdde39d ("device_core: use drain_call_rcu in in qmp_device_add") Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2215192 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2214985 Buglink: https://issues.redhat.com/browse/RHEL-17369 Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20240118144823.1497953-4-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit effd60c878176bcaf97fa7ce2b12d04bb8ead6f7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-28string-output-visitor: Support lists for non-integer typesKevin Wolf1-4/+20
With the introduction of list-based array properties in qdev, the string output visitor has to deal with lists of non-integer elements now ('info qtree' prints all properties with the string output visitor). Currently there is no explicit support for such lists, and the resulting output is only the last element because string_output_set() always replaces the output with the latest value. Instead of replacing the old value, append comma separated values in list context. The difference can be observed in 'info qtree' with a 'rocker' device that has a 'ports' list with more than one element. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231121173416.346610-3-kwolf@redhat.com>
2023-11-15qapi/migration.json: spelling: transferingMichael Tokarev1-1/+1
Fixes: 074dbce5fcce "migration: New migrate and migrate-incoming argument 'channels'" Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-15qapi/pragma.json: Improve the comment about the lists of QAPI rule exceptionsThomas Huth1-2/+2
Let's use more inclusive language here. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-07Merge tag 'pixman-pull-request' of https://gitlab.com/marcandre.lureau/qemu ↵Stefan Hajnoczi1-1/+2
into staging Make Pixman an optional dependency # -----BEGIN PGP SIGNATURE----- # # iQJQBAABCAA6FiEEh6m9kz+HxgbSdvYt2ujhCXWWnOUFAmVKDhkcHG1hcmNhbmRy # ZS5sdXJlYXVAcmVkaGF0LmNvbQAKCRDa6OEJdZac5f8CD/0YX5sXR3IwUfTp8B51 # iIwgOlVunzcT9oDYegIekaHdvggv3B39+gjC/khcehQ30qV6MDowj3ZagIeLavU2 # ZpHJMUkg1YRDHMiJ8aJmDhOyZHINCETWV2YoJX1ACllKOOMSXHC3mWKZd/eIqAPJ # EBMlSWBP1rRtwfaX+p1Y65XappJewzzb9SqFn8s5deowEAM3aK7xafHQOBWSVx9z # 5adhIWn3HMVnbYolVXlcHsPurfI86sqCl7QAqkFdwAvGIKghhqMT6pFfvu3BalHN # nz8GqpSvjlj/WNFABi00piXKx4kkqBJSsYMP8owZQZIeepT5RXuKAB15BA1Cc5N7 # wTkuLe7zXLUST32yAHLa2UZY8Gv/a6C+dH1EFRd7vMMczBPrzwuqzWChRTZPQaX6 # e4uhXnhuu8Io11TnkmwWeWtrLOf+6EmVOjxNwhUUXOqPXPxd7LGMh/ZIc1SuXh0a # k7khpXez4MoBWGftjCEUNlLZ13rcrqnkUWAZeOwjjaqxnYK+Lz32OGS3BtjRYvov # WgogC2c2vVHrSHxRxuytCHiM+7NY0Tf2B6PxZJKOQUtfFxvHjWkHghnJWwHH2OP/ # lMnJUU+XAaAxsiEiDN4BSd0DSA6jn6/vg8SgXXEDyIDExq5jELVMgw2q1cbQJK1s # mOgr8FZZfnxvwYIFvH7PFiDm3A== # =bLPz # -----END PGP SIGNATURE----- # gpg: Signature made Tue 07 Nov 2023 18:14:49 HKT # gpg: using RSA key 87A9BD933F87C606D276F62DDAE8E10975969CE5 # gpg: issuer "marcandre.lureau@redhat.com" # gpg: Good signature from "Marc-André Lureau <marcandre.lureau@redhat.com>" [full] # gpg: aka "Marc-André Lureau <marcandre.lureau@gmail.com>" [full] # Primary key fingerprint: 87A9 BD93 3F87 C606 D276 F62D DAE8 E109 7596 9CE5 * tag 'pixman-pull-request' of https://gitlab.com/marcandre.lureau/qemu: (25 commits) build-sys: make pixman actually optional hw/display/ati: allow compiling without PIXMAN hw/mips: FULOONG depends on VT82C686 hw/sm501: allow compiling without PIXMAN hw/arm: XLNX_VERSAL depends on XLNX_CSU_DMA arm/kconfig: XLNX_ZYNQMP_ARM depends on PIXMAN ui/dbus: do not require PIXMAN ui/gtk: -display gtk requires PIXMAN ui/spice: SPICE/QXL requires PIXMAN ui/vnc: VNC requires PIXMAN ui/gl: opengl doesn't require PIXMAN vhost-user-gpu: skip VHOST_USER_GPU_UPDATE when !PIXMAN ui/console: when PIXMAN is unavailable, don't draw placeholder msg virtio-gpu: replace PIXMAN for region/rect test qmp/hmp: disable screendump if PIXMAN is missing ui/vc: console-vc requires PIXMAN ui/console: allow to override the default VC vl: move display early init before default devices vl: simplify display_remote logic qemu-options: define -vnc only #ifdef CONFIG_VNC ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-11-07qmp/hmp: disable screendump if PIXMAN is missingMarc-André Lureau1-1/+2
The command requires color conversion and line-by-line feeding. We could have a simple fallback for simple formats though. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com>
2023-11-07ui/cocoa: add zoom-to-fit display optionCarwyn Ellis1-1/+6
Provides a display option, zoom-to-fit, that enables scaling of the display when full-screen mode is enabled. Also ensures that the corresponding menu item is marked as enabled when the option is set to on. Signed-off-by: Carwyn Ellis <carwynellis@gmail.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20231027154920.80626-2-carwynellis@gmail.com>
2023-11-07Merge tag 'pull-riscv-to-apply-20231107' of ↵Stefan Hajnoczi1-2/+4
https://github.com/alistair23/qemu into staging Third RISC-V PR for 8.2 * Rename ext_icboz to ext_zicboz * Rename ext_icbom to ext_zicbom * Rename ext_icsr to ext_zicsr * Rename ext_ifencei to ext_zifencei * Add RISC-V Virtual IRQs and IRQ filtering support * Change default linux-user cpu to 'max' * Update 'virt' machine core limit * Add query-cpu-model-expansion API * Rename epmp to smepmp and expose the extension * Clear pmp/smepmp bits on reset * Ignore pmp writes when RW=01 * Support zicntr/zihpm flags and disable support * Correct CSR_MSECCFG operations * Update mail address for Weiwei Li * Update RISC-V vector crypto to ratified v1.0.0 * Clear the Ibex/OpenTitan SPI interrupts even if disabled * Set the OpenTitan priv to 1.12.0 * Support discontinuous PMU counters # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEaukCtqfKh31tZZKWr3yVEwxTgBMFAmVJoOEACgkQr3yVEwxT # gBPwcw/5AXgSVu521IHpobofq4Skc2rpO9P0Hep3IniBuS+5+h2XM3fwWNBaeeGj # LZgdXDrCfcCnPuFh2I5j1D885xJDncDF4LET9EFtxK+BTT8eC5JpaCnORdV3Zd2T # C7qdq1r4J/wKBel3cAz1jlLXc2Pssle4NFaMZGmOGlNX/mLJUYkI6BwKG9wNiCI+ # cCRQW5bEv9g8XzPYPsIKhX9aTegDKdV5x4Xj3YyVs8qkZTVM7Ona8GTpy6eShNfL # h/RW+yvSxLwfKC9YJHesjI1oqhLsAuA7hFu5AVHiedFNAD5FevMZsZwrqjrmeBOG # 5awBw9XgfXFFl7jQ0VQVRknt/PFANzTmGGbjLUkaXgJ6iTmH7oIMzwbkx2pM/0Qd # HV2EboUPe5rJl0SNhcDMCJkYJYpt4z6TVXFpN5p10WU4K1AJXZf9P3YkChcxWiSK # B4DlY4ax3W77voySwbKCvJRIRWCFQZmtl7doFY5dEQz2ERcNfI7VIB1GKIj7BlGm # AVTCc5G9KghsaB8q0BzYbDplzCggdaaUBRgpIgLS/n22GKJlOisFwMCawWquPkEw # i0t3ftt+Ket4Qnnq+dO4W3ehR4qW1/XatCWgQ3NCSgUeS4/9VK3h/nz5t+L7iKwp # mjp86gNN11wcJRsBIIV7nOAmSAs9ybCm2F4J6YAyh3n1IlRVN0Q= # =2A+W # -----END PGP SIGNATURE----- # gpg: Signature made Tue 07 Nov 2023 10:28:49 HKT # gpg: using RSA key 6AE902B6A7CA877D6D659296AF7C95130C538013 # gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 6AE9 02B6 A7CA 877D 6D65 9296 AF7C 9513 0C53 8013 * tag 'pull-riscv-to-apply-20231107' of https://github.com/alistair23/qemu: (49 commits) docs/about/deprecated: Document RISC-V "pmu-num" deprecation target/riscv: Add "pmu-mask" property to replace "pmu-num" target/riscv: Use existing PMU counter mask in FDT generation target/riscv: Don't assume PMU counters are continuous target/riscv: Propagate error from PMU setup target/riscv: cpu: Set the OpenTitan priv to 1.12.0 hw/ssi: ibex_spi_host: Clear the interrupt even if disabled disas/riscv: Replace TABs with space disas/riscv: Add support for vector crypto extensions disas/riscv: Add rv_codec_vror_vi for vror.vi disas/riscv: Add rv_fmt_vd_vs2_uimm format target/riscv: Move vector crypto extensions to riscv_cpu_extensions target/riscv: Expose Zvks[c|g] extnesion properties target/riscv: Add cfg properties for Zvks[c|g] extensions target/riscv: Expose Zvkn[c|g] extnesion properties target/riscv: Add cfg properties for Zvkn[c|g] extensions target/riscv: Expose Zvkb extension property target/riscv: Replace Zvbb checking by Zvkb target/riscv: Add cfg property for Zvkb extension target/riscv: Expose Zvkt extension property ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-11-07Merge tag 'pull-block-2023-11-06' of https://gitlab.com/hreitz/qemu into stagingStefan Hajnoczi1-10/+14
Block patches: - One patch to make qcow2's discard-no-unref option do better what it is supposed to do (i.e. prevent fragmentation) - Two fixes for zoned requests # -----BEGIN PGP SIGNATURE----- # # iQJGBAABCAAwFiEEy2LXoO44KeRfAE00ofpA0JgBnN8FAmVJHbgSHGhyZWl0ekBy # ZWRoYXQuY29tAAoJEKH6QNCYAZzfLn4QAKxuUYZaXirv6K4U2tW4aAJtc5uESdwv # WYhG7YU7MleBGCY0fRoih5thrPrzRLC8o1QhbRcA36+/PAZf4BYrJEfqLUdzuN5x # 6Vb1n3NRUzPD1+VfL/B9hVZhFbtTOUZuxPGEqCoHAmqBaeKuYRT1bLZbtRtPVLSk # 5eTMiyrpRMlBWc7O71eGKLqU4k0vAznwHBGf2Z93qWAsKcRZCwbAWYa7Q6rJ9jJ8 # 1jNsQuAk0p74/uGEpFhoEVrFEcV6pMbI4+jB9i0t9YYxT0tLIdIX1VUx+AHJfItk # IF2stB6SFOaAy2W3Fn+0oJvz40aMLzg9VjEeTpGmdlKC67ZTYa6Obwzy5WNLPIap # k7VUheUEe8qoKUtxQNxGLR/HKEJSFXyhU0lgAGxE1gl2xc1QFFFsrimpwFd3d37j # 3PwfhjARHonf4ZXgsvtIjb7nG9seMZYO7Vht0OztJyW8c2XN5OFVPir9xLbd9VUg # wZNGB8jAsHgj77+S/mRIwpP+laKL8wB7zYZ1mgFI98QJIYqL8tGdV/IiUhLljHzc # XAmwekOhBMMbgHhliBy9zDuTy59+zZ0FoxZPn/JvBjqBAkEnz9EbhHxi2imQg+1d # XSoLbx1X1yEbepWz8mCGiveLIPkt+3qMJuuQF76nURaA+nm3tCl/nKca6QLnVKzU # 2QtPWS0qRmwd # =5w7S # -----END PGP SIGNATURE----- # gpg: Signature made Tue 07 Nov 2023 01:09:12 HKT # gpg: using RSA key CB62D7A0EE3829E45F004D34A1FA40D098019CDF # gpg: issuer "hreitz@redhat.com" # gpg: Good signature from "Hanna Reitz <hreitz@redhat.com>" [unknown] # gpg: WARNING: The key's User ID is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: CB62 D7A0 EE38 29E4 5F00 4D34 A1FA 40D0 9801 9CDF * tag 'pull-block-2023-11-06' of https://gitlab.com/hreitz/qemu: file-posix: fix over-writing of returning zone_append offset block/file-posix: fix update_zones_wp() caller qcow2: keep reference on zeroize with discard-no-unref enabled Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-11-07Merge tag 'pull-hv-balloon-20231106' of ↵Stefan Hajnoczi1-2/+99
https://github.com/maciejsszmigiero/qemu into staging Hyper-V Dynamic Memory protocol driver. This driver is like virtio-balloon on steroids for Windows guests: it allows both changing the guest memory allocation via ballooning and inserting pieces of extra RAM into it on demand from a provided memory backend via Windows-native Hyper-V Dynamic Memory protocol. * Preparatory patches to support empty memory devices and ones with large alignment requirements. * Revert of recently added "hw/virtio/virtio-pmem: Replace impossible check by assertion" commit 5960f254dbb4 since this series makes this situation possible again. * Protocol definitions. * Hyper-V DM protocol driver (hv-balloon) base (ballooning only). * Hyper-V DM protocol driver (hv-balloon) hot-add support. * qapi query-memory-devices support for the driver. * qapi HV_BALLOON_STATUS_REPORT event. * The relevant PC machine plumbing. * New MAINTAINERS entry for the above. # -----BEGIN PGP SIGNATURE----- # # iQGzBAABCAAdFiEE4ndqq6COJv9aG0oJUrHW6VHQzgcFAmVI81IACgkQUrHW6VHQ # zgdzTgv+I5eV2R01YLOBBJhBjzxZ4/BUqkuUHNxHpfjuCqEIzPb7FIfoZ4ZyXZFT # YJdSE4lPeTZLrmmi/Nt6G0rUKDvdCeIgkS2VLHFSsTV8IzcT71BTRGzV0zAjUF5v # yDH6uzo6e9gmaziIalRjibUxSDjCQmoCifms2rS2DwazADudUp+naGfm+3uyA0gM # raOfBfRkNZsDqhXg2ayuqPIES75xQONoON9xYPKDAthS48POEbqtWBKuFopr3kXY # y0eph+NAw+RajCyLYKM3poIgaSu3l4WegInuKQffzqKR8dxrbwPdCmtgo6NSHx0W # uDfl7FUBnGzrR18VU4ZfTSrF5SVscGwF9EL7uocJen15inJjl1q3G53uZgyGzHLC # cw8fKMjucmE8njQR2qiMyX0b+T4+9nKO1rykBgTG/+c9prRUVoxYpFCF117Ei0U8 # QzLGACW1oK+LV41bekWAye7w9pShUtFaxffhPbJeZDDGh7q0x61R3Z3yKkA07p46 # /YWWFWUD # =RAb0 # -----END PGP SIGNATURE----- # gpg: Signature made Mon 06 Nov 2023 22:08:18 HKT # gpg: using RSA key E2776AABA08E26FF5A1B4A0952B1D6E951D0CE07 # gpg: Good signature from "Maciej S. Szmigiero <mail@maciej.szmigiero.name>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 727A 0D4D DB9E D9F6 039B ECEF 847F 5E37 90CE 0977 # Subkey fingerprint: E277 6AAB A08E 26FF 5A1B 4A09 52B1 D6E9 51D0 CE07 * tag 'pull-hv-balloon-20231106' of https://github.com/maciejsszmigiero/qemu: MAINTAINERS: Add an entry for Hyper-V Dynamic Memory Protocol hw/i386/pc: Support hv-balloon qapi: Add HV_BALLOON_STATUS_REPORT event and its QMP query command qapi: Add query-memory-devices support to hv-balloon Add Hyper-V Dynamic Memory Protocol driver (hv-balloon) hot-add support Add Hyper-V Dynamic Memory Protocol driver (hv-balloon) base Add Hyper-V Dynamic Memory Protocol definitions memory-device: Drop size alignment check Revert "hw/virtio/virtio-pmem: Replace impossible check by assertion" memory-device: Support empty memory devices Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-11-07qapi,risc-v: add query-cpu-model-expansionDaniel Henrique Barboza1-2/+4
This API is used to inspect the characteristics of a given CPU model. It also allows users to validate a CPU model with a certain configuration, e.g. if "-cpu X,a=true,b=false" is a valid setup for a given QEMU binary. We'll start implementing the first part. The second requires more changes in RISC-V CPU boot flow. The implementation is inspired by the existing ARM query-cpu-model-expansion impl in target/arm/arm-qmp-cmds.c. We'll create a RISCVCPU object with the required model, fetch its existing properties, add a couple of relevant boolean options (pmp and mmu) and display it to users. Here's an usage example: ./build/qemu-system-riscv64 -S -M virt -display none \ -qmp tcp:localhost:1234,server,wait=off ./scripts/qmp/qmp-shell localhost:1234 Welcome to the QMP low-level shell! Connected to QEMU 8.1.50 (QEMU) query-cpu-model-expansion type=full model={"name":"rv64"} {"return": {"model": {"name": "rv64", "props": {"zicond": false, "x-zvfh": false, "mmu": true, "x-zvfbfwma": false, "x-zvfbfmin": false, "xtheadbs": false, "xtheadbb": false, "xtheadba": false, "xtheadmemidx": false, "smstateen": false, "zfinx": false, "Zve64f": false, "Zve32f": false, "x-zvfhmin": false, "xventanacondops": false, "xtheadcondmov": false, "svpbmt": false, "zbs": true, "zbc": true, "zbb": true, "zba": true, "zicboz": true, "xtheadmac": false, "Zfh": false, "Zfa": true, "zbkx": false, "zbkc": false, "zbkb": false, "Zve64d": false, "x-zfbfmin": false, "zk": false, "x-epmp": false, "xtheadmempair": false, "zkt": false, "zks": false, "zkr": false, "zkn": false, "Zfhmin": false, "zksh": false, "zknh": false, "zkne": false, "zknd": false, "zhinx": false, "Zicsr": true, "sscofpmf": false, "Zihintntl": true, "sstc": true, "xtheadcmo": false, "x-zvbb": false, "zksed": false, "x-zvkned": false, "xtheadsync": false, "x-zvkg": false, "zhinxmin": false, "svadu": true, "xtheadfmv": false, "x-zvksed": false, "svnapot": false, "pmp": true, "x-zvknhb": false, "x-zvknha": false, "xtheadfmemidx": false, "x-zvksh": false, "zdinx": false, "zicbom": true, "Zihintpause": true, "svinval": false, "zcf": false, "zce": false, "zcd": false, "zcb": false, "zca": false, "x-ssaia": false, "x-smaia": false, "zmmul": false, "x-zvbc": false, "Zifencei": true, "zcmt": false, "zcmp": false, "Zawrs": true}}}} Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-06qcow2: keep reference on zeroize with discard-no-unref enabledJean-Louis Dupond1-10/+14
When the discard-no-unref flag is enabled, we keep the reference for normal discard requests. But when a discard is executed on a snapshot/qcow2 image with backing, the discards are saved as zero clusters in the snapshot image. When committing the snapshot to the backing file, not discard_in_l2_slice is called but zero_in_l2_slice. Which did not had any logic to keep the reference when discard-no-unref is enabled. Therefor we add logic in the zero_in_l2_slice call to keep the reference on commit. Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1621 Signed-off-by: Jean-Louis Dupond <jean-louis@dupond.be> Message-Id: <20231003125236.216473-2-jean-louis@dupond.be> [hreitz: Made the documentation change more verbose, as discussed on-list] Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
2023-11-06qapi: Add HV_BALLOON_STATUS_REPORT event and its QMP query commandMaciej S. Szmigiero1-0/+62
Used by the hv-balloon driver for (optional) guest memory status reports. Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
2023-11-06qapi: Add query-memory-devices support to hv-balloonMaciej S. Szmigiero1-2/+37
Used by the driver to report its provided memory state information. Co-developed-by: David Hildenbrand <david@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
2023-11-06Merge tag 'dump-pull-request' of https://gitlab.com/marcandre.lureau/qemu ↵Stefan Hajnoczi1-4/+20
into staging dump queue Hi The "dump" queue, with: - [PATCH v3 qemu 0/3] Allow dump-guest-memory to output standard kdump format - [PATCH v2 0/5] dump: Minor fixes & improvements # -----BEGIN PGP SIGNATURE----- # # iQJQBAABCAA6FiEEh6m9kz+HxgbSdvYt2ujhCXWWnOUFAmVEmsEcHG1hcmNhbmRy # ZS5sdXJlYXVAcmVkaGF0LmNvbQAKCRDa6OEJdZac5YNkD/sFnz+I75mn6+DIdC3x # aSVUU87JxAvWkt+G3KYGS+de2+g2YkRkPwwrIsIceiX7mlL4Es350AVcTl7+fXpu # Jl9k9I32QI+U3pNXo9BStIqjKUMBxmmKs4aLCh9OHJ6oliTCG+aJTUmSl/dABIuw # fAcW9vjhyR4ogAp8x7WhR6PKEAAb6OE/9k0w/z0GV2K09N/R0pPAvObQ36VQJ/Cl # 6DN8tRRytl0IQmC/mZZ+MQPQ5cvamK78X3DmnYCGtyN9HTQERfUFMSSgD/sHLvNi # rMKuwhXiGQfDs/xQ9Z6Vh2AL7JfAwbIQwUstepb78M/5GBLaZfwFYG4+eCohJE82 # s0GOQ45Yks+AOTGj6lNyOfJ8PIf0SocCTbnLWZicpdHIfoEkSmmL0VZ5w+w0EpDO # WOZJRpANJGTLhKNb//X3A3OJ05LoavN3/criokhC19DW/yE/VEGd3dXlP6yvFOku # vGUINGivg1bw7yO0S/rzXNw4+cHCPgBCXbKCNuMI6B+dxL5pUR5Zr4OqcYgwejqE # RWMdqsHA4ohpzc3AfbuHLFilXJNAgLR3jAEiVUXyrz9U1FiYEiq/8RNuupe9Uveq # pO1PDZ9fher0Zda4y28bHl/e5M9hVeCFqElcVk0FQGt97T5olVvSaL/hFUPf65ls # 8A3lN6WaAT9dvM33pkeswZvGxg== # =eSbp # -----END PGP SIGNATURE----- # gpg: Signature made Fri 03 Nov 2023 15:01:21 HKT # gpg: using RSA key 87A9BD933F87C606D276F62DDAE8E10975969CE5 # gpg: issuer "marcandre.lureau@redhat.com" # gpg: Good signature from "Marc-André Lureau <marcandre.lureau@redhat.com>" [full] # gpg: aka "Marc-André Lureau <marcandre.lureau@gmail.com>" [full] # Primary key fingerprint: 87A9 BD93 3F87 C606 D276 F62D DAE8 E109 7596 9CE5 * tag 'dump-pull-request' of https://gitlab.com/marcandre.lureau/qemu: dump: Drop redundant check for empty dump dump: Improve some dump-guest-memory error messages dump: Recognize "fd:" protocols on Windows hosts dump: Fix g_array_unref(NULL) in dump-guest-memory dump: Rename qmp_dump_guest_memory() parameter to match QAPI schema dump: Add command interface for kdump-raw formats dump: Allow directly outputting raw kdump format dump: Pass DumpState to write_ functions Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-11-03target/loongarch: Implement query-cpu-model-expansionSong Gao1-2/+4
Add support for the query-cpu-model-expansion QMP command to LoongArch. We support query the cpu features. e.g la464 and max cpu support LSX/LASX, default enable, la132 not support LSX/LASX. 1. start with '-cpu max,lasx=off' (QEMU) query-cpu-model-expansion type=static model={"name":"max"} {"return": {"model": {"name": "max", "props": {"lasx": false, "lsx": true}}}} 2. start with '-cpu la464,lasx=off' (QEMU) query-cpu-model-expansion type=static model={"name":"la464"} {"return": {"model": {"name": "max", "props": {"lasx": false, "lsx": true}}} 3. start with '-cpu la132,lasx=off' qemu-system-loongarch64: can't apply global la132-loongarch-cpu.lasx=off: Property 'la132-loongarch-cpu.lasx' not found 4. start with '-cpu max,lasx=off' or start with '-cpu la464,lasx=off' query cpu model la132 (QEMU) query-cpu-model-expansion type=static model={"name":"la132"} {"return": {"model": {"name": "la132"}}} Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231020084925.3457084-4-gaosong@loongson.cn>
2023-11-02dump: Add command interface for kdump-raw formatsStephen Brennan1-4/+20
The QMP dump API represents the dump format as an enumeration. Add three new enumerators, one for each supported kdump compression, each named "kdump-raw-*". For the HMP command line, rather than adding a new flag corresponding to each format, it seems more human-friendly to add a single flag "-R" to switch the kdump formats to "raw" mode. The choice of "-R" also correlates nicely to the "makedumpfile -R" option, which would serve to reassemble a flattened vmcore. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> [ Marc-André: replace loff_t with off_t, indent fixes ] Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20230918233233.1431858-4-stephen.s.brennan@oracle.com>
2023-11-02migration: New migrate and migrate-incoming argument 'channels'Het Gala1-1/+112
MigrateChannelList allows to connect accross multiple interfaces. Add MigrateChannelList struct as argument to migration QAPIs. We plan to include multiple channels in future, to connnect multiple interfaces. Hence, we choose 'MigrateChannelList' as the new argument over 'MigrateChannel' to make migration QAPIs future proof. Suggested-by: Aravind Retnakaran <aravind.retnakaran@nutanix.com> Signed-off-by: Het Gala <het.gala@nutanix.com> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231023182053.8711-10-farosas@suse.de>
2023-11-02migration: New QAPI type 'MigrateAddress'Het Gala1-0/+57
This patch introduces well defined MigrateAddress struct and its related child objects. The existing argument of 'migrate' and 'migrate-incoming' QAPI - 'uri' is of type string. The current implementation follows double encoding scheme for fetching migration parameters like 'uri' and this is not an ideal design. Motive for intoducing struct level design is to prevent double encoding of QAPI arguments, as Qemu should be able to directly use the QAPI arguments without any level of encoding. Note: this commit only adds the type, and actual uses comes in later commits. Fabiano fixed for "file" transport. Suggested-by: Aravind Retnakaran <aravind.retnakaran@nutanix.com> Signed-off-by: Het Gala <het.gala@nutanix.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231023182053.8711-2-farosas@suse.de> Message-Id: <20231023182053.8711-3-farosas@suse.de>
2023-11-01cpr: reboot modeSteve Sistare1-1/+14
Add the cpr-reboot migration mode. Usage: $ qemu-system-$arch -monitor stdio ... QEMU 8.1.50 monitor - type 'help' for more information (qemu) migrate_set_capability x-ignore-shared on (qemu) migrate_set_parameter mode cpr-reboot (qemu) migrate -d file:vm.state (qemu) info status VM status: paused (postmigrate) (qemu) quit $ qemu-system-$arch -monitor stdio -incoming defer ... QEMU 8.1.50 monitor - type 'help' for more information (qemu) migrate_set_capability x-ignore-shared on (qemu) migrate_set_parameter mode cpr-reboot (qemu) migrate_incoming file:vm.state (qemu) info status VM status: running In this mode, the migrate command saves state to a file, allowing one to quit qemu, reboot to an updated kernel, and restart an updated version of qemu. The caller must specify a migration URI that writes to and reads from a file. Unlike normal mode, the use of certain local storage options does not block the migration, but the caller must not modify guest block devices between the quit and restart. To avoid saving guest RAM to the file, the memory backend must be shared, and the @x-ignore-shared migration capability must be set. Guest RAM must be non-volatile across reboot, such as by backing it with a dax device, but this is not enforced. The restarted qemu arguments must match those used to initially start qemu, plus the -incoming option. Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <1698263069-406971-6-git-send-email-steven.sistare@oracle.com>
2023-11-01migration: mode parameterSteve Sistare1-3/+24
Create a mode migration parameter that can be used to select alternate migration algorithms. The default mode is normal, representing the current migration algorithm, and does not need to be explicitly set. No functional change until a new mode is added, except that the mode is shown by the 'info migrate' command. Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <1698263069-406971-2-git-send-email-steven.sistare@oracle.com>
2023-11-01Merge tag 'for-upstream' of https://repo.or.cz/qemu/kevin into stagingStefan Hajnoczi2-4/+59
Block layer patches - virtio-blk: use blk_io_plug_call() instead of notification BH - mirror: allow switching from background to active mode - qemu-img rebase: add compression support - Fix locking in media change monitor commands - Fix a few blockjob-related deadlocks when using iothread # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmVBTkERHGt3b2xmQHJl # ZGhhdC5jb20ACgkQfwmycsiPL9ZiqRAAqvsWbblmEGJ7TBKYQK3f8QshJ66RxzbC # 4eSjKHrciWNTeeIeU8r8OvFcPPoTcPXxpcmasD2gsAxG5W5N8vkPbBkW+YT4YdDJ # pWJXrbJ15nILC4DmnR1ARVtvxKgv9zy5LSm5bjss1K+OSYJl/nx+ILjmfVZnYDF7 # z1dP/G0JxKKm4JzAIdBE3uZS+6Q5kx/wGYlJv8EQmlH3DYfsJfy6Lthe9jfw8ijg # lSqLoQ+D0lEd6Bk4XbkUqqBxFcYBWTfU6qPZoyIO94zCTwTG9yIjmoivxmmfwQZq # cJUTGGZjcxpJYnvcC6P13WgcWBtcD9L2kYFVH0JyjpwcSg9cCGHMF66n9pSlyEGq # DUikwVzbTwOotwzYQyM88v4ET+2+Qdcwn8pRbv9PllEczh0kAsUAEuxSgtz4NEcN # bZrap/16xHFybNOKkMZcmpqxspT5NXKbDODUP0IvbSYMOYpWS983nBTxwMRpyHog # 2TFDZu4DjNiPkI2BcYM5VOKk6diNowZFShcEKvoaOLX/n9EBhP0tjoH9VUn1800F # myHrhF2jpIf9GhErMWB7N2W3/0aK0pqdQgbpVnd1ARDdIdYkr7G/S+50D9K80b6n # 0q2E7br4S5bcsY0HQzBL9YARSayY+lVOssLoolCWEsYzijdBQmAvs5THajFKcism # /idI6nlp2Vs= # =RdxS # -----END PGP SIGNATURE----- # gpg: Signature made Wed 01 Nov 2023 03:58:09 JST # gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6 # gpg: issuer "kwolf@redhat.com" # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full] # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * tag 'for-upstream' of https://repo.or.cz/qemu/kevin: (27 commits) iotests: add test for changing mirror's copy_mode mirror: return mirror-specific information upon query blockjob: query driver-specific info via a new 'query' driver method qapi/block-core: turn BlockJobInfo into a union qapi/block-core: use JobType for BlockJobInfo's type mirror: implement mirror_change method block/mirror: determine copy_to_target only once block/mirror: move dirty bitmap to filter block/mirror: set actively_synced even after the job is ready blockjob: introduce block-job-change QMP command virtio-blk: remove batch notification BH virtio: use defer_call() in virtio_irqfd_notify() util/defer-call: move defer_call() to util/ block: rename blk_io_plug_call() API to defer_call() blockdev: mirror: avoid potential deadlock when using iothread block: avoid potential deadlock during bdrv_graph_wrlock() in bdrv_close() blockjob: drop AioContext lock before calling bdrv_graph_wrlock() iotests: Test media change with iothreads block: Fix locking in media change monitor commands iotests: add tests for "qemu-img rebase" with compression ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-10-31mirror: return mirror-specific information upon queryFiona Ebner1-1/+15
To start out, only actively-synced is returned. For example, this is useful for jobs that started out in background mode and switched to active mode. Once actively-synced is true, it's clear that the mode switch has been completed. Note that completion of the switch might happen much earlier, e.g. if the switch happens before the job is ready, once all background operations have finished. It's assumed that whether the disks are actively-synced or not is more interesting than whether the mode switch completed. That information can still be added if required in the future. In presence of an iothread, the actively_synced member is now shared between the iothread and the main thread, so turn accesses to it atomic. Requires to adapt the output for iotest 109. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20231031135431.393137-10-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31qapi/block-core: turn BlockJobInfo into a unionFiona Ebner1-3/+5
In preparation to additionally return job-type-specific information. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-ID: <20231031135431.393137-8-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31qapi/block-core: use JobType for BlockJobInfo's typeFiona Ebner1-1/+1
In preparation to turn BlockJobInfo into a union with @type as the discriminator. That requires it to be an enum. Even without that requirement, it's nicer to have an enum instead of a str here. No functional change is intended. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20231031135431.393137-7-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31mirror: implement mirror_change methodFiona Ebner1-1/+12
which allows switching the @copy-mode from 'background' to 'write-blocking'. This is useful for management applications, so they can start out in background mode to avoid limiting guest write speed and switch to active mode when certain criteria are fulfilled. In presence of an iothread, the copy_mode member is now shared between the iothread and the main thread, so turn accesses to it atomic. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20231031135431.393137-6-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31blockjob: introduce block-job-change QMP commandFiona Ebner2-1/+29
which will allow changing job-type-specific options after job creation. In the JobVerbTable, the same allow bits as for set-speed are used, because set-speed can be considered an existing change command. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-ID: <20231031135431.393137-2-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31migration: Deprecate old compression methodJuan Quintela1-20/+43
Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Peter Xu <peterx@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231018115513.2163-6-quintela@redhat.com>
2023-10-31migration: Deprecate block migrationJuan Quintela1-5/+24
It is obsolete. It is better to use driver-mirror with NBD instead. CC: Kevin Wolf <kwolf@redhat.com> CC: Eric Blake <eblake@redhat.com> CC: Stefan Hajnoczi <stefanha@redhat.com> CC: Hanna Czenczek <hreitz@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231018115513.2163-5-quintela@redhat.com>
2023-10-31migration: migrate 'blk' command option is deprecated.Juan Quintela1-3/+4
Use blocked-mirror with NBD instead. Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231018115513.2163-4-quintela@redhat.com>
2023-10-31migration: migrate 'inc' command option is deprecated.Juan Quintela1-1/+7
Use blockdev-mirror with NBD instead. Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231018115513.2163-3-quintela@redhat.com>
2023-10-20Merge tag 'pull-request-2023-10-20' of https://gitlab.com/thuth/qemu into ↵Stefan Hajnoczi5-22/+207
staging * s390x CPU topology support * Simplify the KVM register synchronization code * Disable the analyze-migration.py test on s390x # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmUyDYMRHHRodXRoQHJl # ZGhhdC5jb20ACgkQLtnXdP5wLbUlgBAAkF3dvW0vMcb653sCI5vt2GHIvQQtc2Rw # ghRRcTBZ7wyVxKHtqohCh7/byzDW5YEuCWUyLsc2oIz/84pc00VR/5Ng1EAxLAfe # mvzzjr4jX96SmoO0DbJpqJQXaUPNYdmoshbRL0I3wkIfGtkvGRM8zHZuYINOg0hw # bH6gWZ2QL/NFjXh0uAOaJB1+hRtPWvHD2rnVt0g9U9W5QhRxGJqti5YEaLBH7hh5 # RydsquRZ/E6uFw4pMjjvCxDaswPwejddrP2YeR5Fd5Zo+Kzp53r9Hf/eJwlZ8yFL # 5f1dRb19NZYpW1hZuJVOP8tkPydYxAM85vkUunI7Qg4gez5KI0Nz6hQozw6ufMlQ # r8L17fwQMsCrwcRypImYNXyyrtHlNH5Y8FjqTct8aK64Bw3e7Qqi7d3ybFAuYZ+D # k2EJ8Rlwhbg69h+Q+ucHx4NkYu9+2MFS6G7w5EcM6xl3WHSwUxh9orlEMsIkyHS3 # OMFMTr1jjfFdEN6EafhPwFE/xKglFF2Fe3u6NoR+5pkv3UA5Z87giitxoekYecpH # J96P3anORpWW75qvOF+nccqrd7OrUL1/yYdOyJh5Tkm0oCIeQ9E5extVf3Gne3E/ # yWzr00GJRiHFO2qbGStgKHTQLItgQpccwNpSzEdgHCqwLbXl6e3Hoq42VIFOlbN/ # ZtgpyUkuYyQ= # =xDb+ # -----END PGP SIGNATURE----- # gpg: Signature made Thu 19 Oct 2023 22:17:55 PDT # gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5 # gpg: issuer "thuth@redhat.com" # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * tag 'pull-request-2023-10-20' of https://gitlab.com/thuth/qemu: (24 commits) tests/qtest/migration-test: Disable the analyze-migration.py test on s390x target/s390x/kvm: Simplify the GPRs, ACRs, CRs and prefix synchronization code target/s390x/kvm: Turn KVM_CAP_SYNC_REGS into a hard requirement tests/avocado: s390x cpu topology bad move tests/avocado: s390x cpu topology dedicated errors tests/avocado: s390x cpu topology test socket full tests/avocado: s390x cpu topology test dedicated CPU tests/avocado: s390x cpu topology entitlement tests tests/avocado: s390x cpu topology polarization tests/avocado: s390x cpu topology core docs/s390x/cpu topology: document s390x cpu topology qapi/s390x/cpu topology: add query-s390x-cpu-polarization command qapi/s390x/cpu topology: CPU_POLARIZATION_CHANGE QAPI event machine: adding s390 topology to info hotpluggable-cpus machine: adding s390 topology to query-cpu-fast qapi/s390x/cpu topology: set-cpu-topology qmp command target/s390x/cpu topology: activate CPU topology s390x/cpu topology: interception of PTF instruction s390x/cpu topology: resetting the Topology-Change-Report s390x/sclp: reporting the maximum nested topology entries ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-10-20docs/s390x/cpu topology: document s390x cpu topologyPierre Morel1-0/+2
Add some basic examples for the definition of cpu topology in s390x. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-15-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-20qapi/s390x/cpu topology: add query-s390x-cpu-polarization commandPierre Morel1-0/+30
The query-s390x-cpu-polarization qmp command returns the current CPU polarization of the machine. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-14-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-20qapi/s390x/cpu topology: CPU_POLARIZATION_CHANGE QAPI eventPierre Morel1-0/+35
When the guest asks to change the polarization this change is forwarded to the upper layer using QAPI. The upper layer is supposed to take according decisions concerning CPU provisioning. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-13-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-20machine: adding s390 topology to query-cpu-fastPierre Morel1-1/+8
S390x provides two more topology attributes, entitlement and dedication. Let's add these CPU attributes to the QAPI command query-cpu-fast. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-11-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-20qapi/s390x/cpu topology: set-cpu-topology qmp commandPierre Morel1-0/+42
The modification of the CPU attributes are done through a monitor command. It allows to move the core inside the topology tree to optimize the cache usage in the case the host's hypervisor previously moved the CPU. The same command allows to modify the CPU attributes modifiers like polarization entitlement and the dedicated attribute to notify the guest if the host admin modified scheduling or dedication of a vCPU. With this knowledge the guest has the possibility to optimize the usage of the vCPUs. The command has a feature unstable for the moment. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Acked-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20231016183925.2384704-10-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-20target/s390x/cpu topology: handle STSI(15) and build the SYSIBPierre Morel1-0/+14
On interception of STSI(15.1.x) the System Information Block (SYSIB) is built from the list of pre-ordered topology entries. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-5-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-20CPU topology: extend with s390 specificsPierre Morel4-3/+41
S390 adds two new SMP levels, drawers and books to the CPU topology. S390 CPUs have specific topology features like dedication and entitlement. These indicate to the guest information on host vCPU scheduling and help the guest make better scheduling decisions. Add the new levels to the relevant QAPI structs. Add all the supported topology levels, dedication and entitlement as properties to S390 CPUs. Create machine-common.json so we can later include it in machine-target.json also. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-3-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-20qapi: machine.json: change docs regarding CPU topologyNina Schoetterl-Glausch1-21/+38
Clarify roles of different architectures. Also change things a bit in anticipation of additional members being added. Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-2-nsg@linux.ibm.com> Acked-by: Markus Armbruster <armbru@redhat.com> [thuth: Updated some comments according to suggestions from Markus] Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-19qapi: Belatedly update CompatPolicy documentation for unstableMarkus Armbruster1-2/+2
Commit 57df0dff1a1 (qapi: Extend -compat to set policy for unstable interfaces) neglected to update the "Limitation" paragraph to mention feature 'unstable' in addition to feature 'deprecated'. Do that now. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20231009110449.4015601-1-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-10-17migration: Improve json and formattingJuan Quintela1-4/+3
Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231013104736.31722-2-quintela@redhat.com>
2023-10-17migration: Allow user to specify available switchover bandwidthPeter Xu1-1/+33
Migration bandwidth is a very important value to live migration. It's because it's one of the major factors that we'll make decision on when to switchover to destination in a precopy process. This value is currently estimated by QEMU during the whole live migration process by monitoring how fast we were sending the data. This can be the most accurate bandwidth if in the ideal world, where we're always feeding unlimited data to the migration channel, and then it'll be limited to the bandwidth that is available. However in reality it may be very different, e.g., over a 10Gbps network we can see query-migrate showing migration bandwidth of only a few tens of MB/s just because there are plenty of other things the migration thread might be doing. For example, the migration thread can be busy scanning zero pages, or it can be fetching dirty bitmap from other external dirty sources (like vhost or KVM). It means we may not be pushing data as much as possible to migration channel, so the bandwidth estimated from "how many data we sent in the channel" can be dramatically inaccurate sometimes. With that, the decision to switchover will be affected, by assuming that we may not be able to switchover at all with such a low bandwidth, but in reality we can. The migration may not even converge at all with the downtime specified, with that wrong estimation of bandwidth, keeping iterations forever with a low estimation of bandwidth. The issue is QEMU itself may not be able to avoid those uncertainties on measuing the real "available migration bandwidth". At least not something I can think of so far. One way to fix this is when the user is fully aware of the available bandwidth, then we can allow the user to help providing an accurate value. For example, if the user has a dedicated channel of 10Gbps for migration for this specific VM, the user can specify this bandwidth so QEMU can always do the calculation based on this fact, trusting the user as long as specified. It may not be the exact bandwidth when switching over (in which case qemu will push migration data as fast as possible), but much better than QEMU trying to wildly guess, especially when very wrong. A new parameter "avail-switchover-bandwidth" is introduced just for this. So when the user specified this parameter, instead of trusting the estimated value from QEMU itself (based on the QEMUFile send speed), it trusts the user more by using this value to decide when to switchover, assuming that we'll have such bandwidth available then. Note that specifying this value will not throttle the bandwidth for switchover yet, so QEMU will always use the full bandwidth possible for sending switchover data, assuming that should always be the most important way to use the network at that time. This can resolve issues like "unconvergence migration" which is caused by hilarious low "migration bandwidth" detected for whatever reason. Reported-by: Zhiyi Guo <zhguo@redhat.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231010221922.40638-1-peterx@redhat.com>
2023-10-11migration: Display error in query-migrate irrelevant of statusPeter Xu1-3/+2
Display it as long as being set, irrelevant of FAILED status. E.g., it may also be applicable to PAUSED stage of postcopy, to provide hint on what has gone wrong. The error_mutex seems to be overlooked when referencing the error, add it to be very safe. This will change QAPI behavior by showing up error message outside !FAILED status, but it's intended and doesn't expect to break anyone. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2018404 Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231004220240.167175-2-peterx@redhat.com>
2023-10-10migration/dirtyrate: use QEMU_CLOCK_HOST to report start-timeAndrei Gudkov1-2/+2
Currently query-dirty-rate uses QEMU_CLOCK_REALTIME as the source for start-time field. This translates to clock_gettime(CLOCK_MONOTONIC), i.e. number of seconds since host boot. This is not very useful. The only reasonable use case of start-time I can imagine is to check whether previously completed measurements are too old or not. But this makes sense only if start-time is reported as host wall-clock time. This patch replaces source of start-time from QEMU_CLOCK_REALTIME to QEMU_CLOCK_HOST. Signed-off-by: Andrei Gudkov <gudkov.andrei@huawei.com> Reviewed-by: Hyman Huang <yong.huang@smartx.com> Message-Id: <399861531e3b24a1ecea2ba453fb2c3d129fb03a.1693905328.git.gudkov.andrei@huawei.com> Signed-off-by: Hyman Huang <yong.huang@smartx.com>
2023-10-10migration/calc-dirty-rate: millisecond-granularity periodAndrei Gudkov1-11/+47
This patch allows to measure dirty page rate for sub-second intervals of time. An optional argument is introduced -- calc-time-unit. For example: {"execute": "calc-dirty-rate", "arguments": {"calc-time": 500, "calc-time-unit": "millisecond"} } Millisecond granularity allows to make predictions whether migration will succeed or not. To do this, calculate dirty rate with calc-time set to max allowed downtime (e.g. 300ms), convert measured rate into volume of dirtied memory, and divide by network throughput. If the value is lower than max allowed downtime, then migration will converge. Measurement results for single thread randomly writing to a 1/4/24GiB memory region: +----------------+-----------------------------------------------+ | calc-time | dirty rate MiB/s | | (milliseconds) +----------------+---------------+--------------+ | | theoretical | page-sampling | dirty-bitmap | | | (at 3M wr/sec) | | | +----------------+----------------+---------------+--------------+ | 1GiB | +----------------+----------------+---------------+--------------+ | 100 | 6996 | 7100 | 3192 | | 200 | 4606 | 4660 | 2655 | | 300 | 3305 | 3280 | 2371 | | 400 | 2534 | 2525 | 2154 | | 500 | 2041 | 2044 | 1871 | | 750 | 1365 | 1341 | 1358 | | 1000 | 1024 | 1052 | 1025 | | 1500 | 683 | 678 | 684 | | 2000 | 512 | 507 | 513 | +----------------+----------------+---------------+--------------+ | 4GiB | +----------------+----------------+---------------+--------------+ | 100 | 10232 | 8880 | 4070 | | 200 | 8954 | 8049 | 3195 | | 300 | 7889 | 7193 | 2881 | | 400 | 6996 | 6530 | 2700 | | 500 | 6245 | 5772 | 2312 | | 750 | 4829 | 4586 | 2465 | | 1000 | 3865 | 3780 | 2178 | | 1500 | 2694 | 2633 | 2004 | | 2000 | 2041 | 2031 | 1789 | +----------------+----------------+---------------+--------------+ | 24GiB | +----------------+----------------+---------------+--------------+ | 100 | 11495 | 8640 | 5597 | | 200 | 11226 | 8616 | 3527 | | 300 | 10965 | 8386 | 2355 | | 400 | 10713 | 8370 | 2179 | | 500 | 10469 | 8196 | 2098 | | 750 | 9890 | 7885 | 2556 | | 1000 | 9354 | 7506 | 2084 | | 1500 | 8397 | 6944 | 2075 | | 2000 | 7574 | 6402 | 2062 | +----------------+----------------+---------------+--------------+ Theoretical values are computed according to the following formula: size * (1 - (1-(4096/size))^(time*wps)) / (time * 2^20), where size is in bytes, time is in seconds, and wps is number of writes per second. Signed-off-by: Andrei Gudkov <gudkov.andrei@huawei.com> Reviewed-by: Hyman Huang <yong.huang@smartx.com> Message-Id: <d802e6b8053eb60fbec1a784cf86f67d9528e0a8.1693895970.git.gudkov.andrei@huawei.com> Signed-off-by: Hyman Huang <yong.huang@smartx.com>
2023-09-20qemu-img: map: report compressed data blocksAndrey Drobyshev via1-2/+4
Right now "qemu-img map" reports compressed blocks as containing data but having no host offset. This is not very informative. Instead, let's add another boolean field named "compressed" in case JSON output mode is specified. This is achieved by utilizing new allocation status flag BDRV_BLOCK_COMPRESSED for bdrv_block_status(). Also update the expected qemu-iotests outputs to contain the new field. Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Message-ID: <20230907210226.953821-3-andrey.drobyshev@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-09-19Merge tag 'mem-2023-09-19' of https://github.com/davidhildenbrand/qemu into ↵Stefan Hajnoczi1-1/+16
staging Hi, "Host Memory Backends" and "Memory devices" queue ("mem"): - Support and document VM templating with R/O files using a new "rom" parameter for memory-backend-file - Some cleanups and fixes around NVDIMMs and R/O file handling for guest RAM - Optimize ioeventfd updates by skipping address spaces that are not applicable # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAmUJdykRHGRhdmlkQHJl # ZGhhdC5jb20ACgkQTd4Q9wD/g1pf2w//akOUoYMuamySGjXtKLVyMKZkjIys+Ama # k2C0xzsWAHBP572ezwHi8uxf5j9kzAjsw6GxDZ7FAamD9MhiohkEvkecloBx6f/c # q3fVHblBNkG7v2urtf4+6PJtJvhzOST2SFXfWeYhO/vaA04AYCDgexv82JN3gA6B # OS8WyOX62b8wILPSY2GLZ8IqpE9XnOYZwzVBn6YB1yo7ZkYEfXO6cA8nykNuNcOE # vppqDo7uVIX6317FWj8ygxmzFfOaj0WT2MT2XFzEIDfg8BInQN8HC4mTn0hcVKMa # N1y+eZH733CQKT+uNBRZ5YOeljOi4d6gEEyvkkA/L7e5D3Qg9hIdvHb4uryCFSWX # Vt07OP1XLBwCZFobOC6sg+2gtTZJxxYK89e6ZzEd0454S24w5bnEteRAaCGOP0XL # ww9xYULqhtZs55UC4rvZHJwdUAk1fIY4VqynwkeQXegvz6BxedNeEkJiiEU0Tizx # N2VpsxAJ7H/LLSFeZoCRESo4azrH6U4n7S/eS1tkCniFqibfe2yIQCDoJVfb42ec # gfg/vThCrDwHkIHzkMmoV8NndA7Q7SIkyMfYeEEBeZMeg8JzYll4DJEw/jQCacxh # KRUa+AZvGlTJUq0mkvyOVfLki+iaehoIUuY1yvMrmdWijPO8n3YybmP9Ljhr8VdR # 9MSYZe+I2v8= # =iraT # -----END PGP SIGNATURE----- # gpg: Signature made Tue 19 Sep 2023 06:25:45 EDT # gpg: using RSA key 1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A # gpg: issuer "david@redhat.com" # gpg: Good signature from "David Hildenbrand <david@redhat.com>" [unknown] # gpg: aka "David Hildenbrand <davidhildenbrand@gmail.com>" [full] # gpg: aka "David Hildenbrand <hildenbr@in.tum.de>" [unknown] # gpg: WARNING: The key's User ID is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 1BD9 CAAD 735C 4C3A 460D FCCA 4DDE 10F7 00FF 835A * tag 'mem-2023-09-19' of https://github.com/davidhildenbrand/qemu: memory: avoid updating ioeventfds for some address_space machine: Improve error message when using default RAM backend id softmmu/physmem: Hint that "readonly=on,rom=off" exists when opening file R/W for private mapping fails docs: Start documenting VM templating docs: Don't mention "-mem-path" in multi-process.rst softmmu/physmem: Never return directories from file_ram_open() softmmu/physmem: Fail creation of new files in file_ram_open() with readonly=true softmmu/physmem: Bail out early in ram_block_discard_range() with readonly files softmmu/physmem: Remap with proper protection in qemu_ram_remap() backends/hostmem-file: Add "rom" property to support VM templating with R/O files softmmu/physmem: Distinguish between file access mode and mmap protection nvdimm: Reject writing label data to ROM instead of crashing QEMU Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-09-19backends/hostmem-file: Add "rom" property to support VM templating with R/O ↵David Hildenbrand1-1/+16
files For now, "share=off,readonly=on" would always result in us opening the file R/O and mmap'ing the opened file MAP_PRIVATE R/O -- effectively turning it into ROM. Especially for VM templating, "share=off" is a common use case. However, that use case is impossible with files that lack write permissions, because "share=off,readonly=on" will not give us writable RAM. The sole user of ROM via memory-backend-file are R/O NVDIMMs, but as we have users (Kata Containers) that rely on the existing behavior -- malicious VMs should not be able to consume COW memory for R/O NVDIMMs -- we cannot change the semantics of "share=off,readonly=on" So let's add a new "rom" property with on/off/auto values. "auto" is the default and what most people will use: for historical reasons, to not change the old semantics, it defaults to the value of the "readonly" property. For VM templating, one can now use: -object memory-backend-file,share=off,readonly=on,rom=off,... But we'll disallow: -object memory-backend-file,share=on,readonly=on,rom=off,... because we would otherwise get an error when trying to mmap the R/O file shared and writable. An explicit error message is cleaner. We will also disallow for now: -object memory-backend-file,share=off,readonly=off,rom=on,... -object memory-backend-file,share=on,readonly=off,rom=on,... It's not harmful, but also not really required for now. Alternatives that were abandoned: * Make "unarmed=on" for the NVDIMM set the memory region container readonly. We would still see a change of ROM->RAM and possibly run into memslot limits with vhost-user. Further, there might be use cases for "unarmed=on" that should still allow writing to that memory (temporary files, system RAM, ...). * Add a new "readonly=on/off/auto" parameter for NVDIMMs. Similar issues as with "unarmed=on". * Make "readonly" consume "on/off/file" instead of being a 'bool' type. This would slightly changes the behavior of the "readonly" parameter: values like true/false (as accepted by a 'bool'type) would no longer be accepted. Message-ID: <20230906120503.359863-4-david@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-09-18net: add initial support for AF_XDP network backendIlya Maximets1-0/+58
AF_XDP is a network socket family that allows communication directly with the network device driver in the kernel, bypassing most or all of the kernel networking stack. In the essence, the technology is pretty similar to netmap. But, unlike netmap, AF_XDP is Linux-native and works with any network interfaces without driver modifications. Unlike vhost-based backends (kernel, user, vdpa), AF_XDP doesn't require access to character devices or unix sockets. Only access to the network interface itself is necessary. This patch implements a network backend that communicates with the kernel by creating an AF_XDP socket. A chunk of userspace memory is shared between QEMU and the host kernel. 4 ring buffers (Tx, Rx, Fill and Completion) are placed in that memory along with a pool of memory buffers for the packet data. Data transmission is done by allocating one of the buffers, copying packet data into it and placing the pointer into Tx ring. After transmission, device will return the buffer via Completion ring. On Rx, device will take a buffer form a pre-populated Fill ring, write the packet data into it and place the buffer into Rx ring. AF_XDP network backend takes on the communication with the host kernel and the network interface and forwards packets to/from the peer device in QEMU. Usage example: -device virtio-net-pci,netdev=guest1,mac=00:16:35:AF:AA:5C -netdev af-xdp,ifname=ens6f1np1,id=guest1,mode=native,queues=1 XDP program bridges the socket with a network interface. It can be attached to the interface in 2 different modes: 1. skb - this mode should work for any interface and doesn't require driver support. With a caveat of lower performance. 2. native - this does require support from the driver and allows to bypass skb allocation in the kernel and potentially use zero-copy while getting packets in/out userspace. By default, QEMU will try to use native mode and fall back to skb. Mode can be forced via 'mode' option. To force 'copy' even in native mode, use 'force-copy=on' option. This might be useful if there is some issue with the driver. Option 'queues=N' allows to specify how many device queues should be open. Note that all the queues that are not open are still functional and can receive traffic, but it will not be delivered to QEMU. So, the number of device queues should generally match the QEMU configuration, unless the device is shared with something else and the traffic re-direction to appropriate queues is correctly configured on a device level (e.g. with ethtool -N). 'start-queue=M' option can be used to specify from which queue id QEMU should start configuring 'N' queues. It might also be necessary to use this option with certain NICs, e.g. MLX5 NICs. See the docs for examples. In a general case QEMU will need CAP_NET_ADMIN and CAP_SYS_ADMIN or CAP_BPF capabilities in order to load default XSK/XDP programs to the network interface and configure BPF maps. It is possible, however, to run with no capabilities. For that to work, an external process with enough capabilities will need to pre-load default XSK program, create AF_XDP sockets and pass their file descriptors to QEMU process on startup via 'sock-fds' option. Network backend will need to be configured with 'inhibit=on' to avoid loading of the program. QEMU will need 32 MB of locked memory (RLIMIT_MEMLOCK) per queue or CAP_IPC_LOCK. There are few performance challenges with the current network backends. First is that they do not support IO threads. This means that data path is handled by the main thread in QEMU and may slow down other work or may be slowed down by some other work. This also means that taking advantage of multi-queue is generally not possible today. Another thing is that data path is going through the device emulation code, which is not really optimized for performance. The fastest "frontend" device is virtio-net. But it's not optimized for heavy traffic either, because it expects such use-cases to be handled via some implementation of vhost (user, kernel, vdpa). In practice, we have virtio notifications and rcu lock/unlock on a per-packet basis and not very efficient accesses to the guest memory. Communication channels between backend and frontend devices do not allow passing more than one packet at a time as well. Some of these challenges can be avoided in the future by adding better batching into device emulation or by implementing vhost-af-xdp variant. There are also a few kernel limitations. AF_XDP sockets do not support any kinds of checksum or segmentation offloading. Buffers are limited to a page size (4K), i.e. MTU is limited. Multi-buffer support implementation for AF_XDP is in progress, but not ready yet. Also, transmission in all non-zero-copy modes is synchronous, i.e. done in a syscall. That doesn't allow high packet rates on virtual interfaces. However, keeping in mind all of these challenges, current implementation of the AF_XDP backend shows a decent performance while running on top of a physical NIC with zero-copy support. Test setup: 2 VMs running on 2 physical hosts connected via ConnectX6-Dx card. Network backend is configured to open the NIC directly in native mode. The driver supports zero-copy. NIC is configured to use 1 queue. Inside a VM - iperf3 for basic TCP performance testing and dpdk-testpmd for PPS testing. iperf3 result: TCP stream : 19.1 Gbps dpdk-testpmd (single queue, single CPU core, 64 B packets) results: Tx only : 3.4 Mpps Rx only : 2.0 Mpps L2 FWD Loopback : 1.5 Mpps In skb mode the same setup shows much lower performance, similar to the setup where pair of physical NICs is replaced with veth pair: iperf3 result: TCP stream : 9 Gbps dpdk-testpmd (single queue, single CPU core, 64 B packets) results: Tx only : 1.2 Mpps Rx only : 1.0 Mpps L2 FWD Loopback : 0.7 Mpps Results in skb mode or over the veth are close to results of a tap backend with vhost=on and disabled segmentation offloading bridged with a NIC. Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> (docker/lcitool) Signed-off-by: Jason Wang <jasowang@redhat.com>
generated by cgit v1.1 at 2024-12-24 01:00:51 +0000