[Qemu-commits] [qemu/qemu] 7b28c6: vhost-net: move stubs to a separate f

qemu-commits
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 7b28c6: vhost-net: move stubs to a separate f

From:	Peter Maydell
Subject:	[Qemu-commits] [qemu/qemu] 7b28c6: vhost-net: move stubs to a separate file
Date:	Mon, 04 Mar 2019 13:37:44 +0000 (UTC)
  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 7b28c61524540e325e241aa31e6f10e99a5a9516
      
https://github.com/qemu/qemu/commit/7b28c61524540e325e241aa31e6f10e99a5a9516
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M hw/net/Makefile.objs
    A hw/net/vhost_net-stub.c
    M hw/net/vhost_net.c

  Log Message:
  -----------
  vhost-net: move stubs to a separate file

There is no reason for CONFIG_VHOST_NET to be specific to a single target;
it is a host feature that can be add to all targets, as long as they support
the virtio-net device.  Currently CONFIG_VHOST_NET depends on CONFIG_KVM,
but ioeventfd support is present in the core memory API and works with
other accelerators as well.

As a first step, move the vhost-net stubs to a separate file.  Later, they
will become conditional on CONFIG_VIRTIO_NET, which is not available in .c
files.

Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 56f41de7372eb81e751e65942e7ec928e07fb67e
      
https://github.com/qemu/qemu/commit/56f41de7372eb81e751e65942e7ec928e07fb67e
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M configure
    M hw/net/vhost_net.c
    M net/Makefile.objs
    M net/net.c
    A net/vhost-user-stub.c

  Log Message:
  -----------
  vhost-net-user: add stubs for when no virtio-net device is present

hw/net/vhost_net.c needs functions that are declared in net/vhost-user.c: the
vhost-user code is always compiled into QEMU, only the constructor
net_init_vhost_user is unreachable.  Also, net/vhost-user.c needs functions
declared in hw/virtio/vhost-stub.c even if no virtio device exists.

Break this dependency.  First, add a minimal version of net/vhost-user.c,
with no functionality and no dependency on vhost code.  Second, #ifdef out
the calls back to net/vhost-user.c from hw/net/vhost_net.c.

While at it, this patch fixes the CONFIG_VHOST_NET_USE*D* typo.

Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 18658a3ced71e0fb23a0ef80ef0bbf1a9cbb7a2b
      
https://github.com/qemu/qemu/commit/18658a3ced71e0fb23a0ef80ef0bbf1a9cbb7a2b
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M backends/Makefile.objs
    M default-configs/virtio.mak
    M hw/net/vhost_net.c
    M hw/virtio/Makefile.objs
    M hw/virtio/vhost-backend.c
    M hw/virtio/vhost-user.c
    M hw/virtio/vhost.c

  Log Message:
  -----------
  vhost: restrict Linux dependency to kernel vhost

vhost-user does not depend on Linux; it can run on any POSIX system.  Restrict
vhost-kernel to Linux in hw/virtio/vhost-backend.c, everything else can be
compiled on all POSIX systems.

Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: ba28889838e6bdce540f30892d547cf634c1b0cd
      
https://github.com/qemu/qemu/commit/ba28889838e6bdce540f30892d547cf634c1b0cd
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M net/vhost-user.c

  Log Message:
  -----------
  vhost-user: support cross-endian vnet headers

vhost-user already has a way to communicate the endianness of the guest
via the vring endianness messages.  The vring endianness always matches
the vnet header endianness so there is no need to do anything else in
the backend.

Reviewed-by: Marc-André Lureau <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: af3bba761a1208c8515bcc72fc48d0f9045d040c
      
https://github.com/qemu/qemu/commit/af3bba761a1208c8515bcc72fc48d0f9045d040c
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M configure
    M hw/net/Makefile.objs
    M hw/net/vhost_net.c
    M include/exec/poison.h
    M tests/Makefile.include
    M tests/vhost-user-test.c

  Log Message:
  -----------
  vhost-net: compile it on all targets that have virtio-net.

This shows a preexisting bug: if a KVM target did not have virtio-net enabled,
it would fail with undefined symbols when vhost was enabled.  This must now
be fixed, lest targets that have no virtio-net fail to compile.

Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Message-Id: <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 299e6f19b3e285f3ab00b780e3b48f5e58b5d4ed
      
https://github.com/qemu/qemu/commit/299e6f19b3e285f3ab00b780e3b48f5e58b5d4ed
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M configure
    M hw/virtio/Makefile.objs
    M hw/virtio/vhost-backend.c

  Log Message:
  -----------
  vhost-net: revamp configure logic

Detect all invalid configurations (e.g. mingw32 with vhost-user,
non-Linux with vhost-kernel).  As a collateral benefit, all vhost-kernel
backends can be now disabled if one wants to reduce the attack surface.

Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Message-Id: <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 7d0ca3e747ce3b595fcae554b04fccbffd0c04f0
      
https://github.com/qemu/qemu/commit/7d0ca3e747ce3b595fcae554b04fccbffd0c04f0
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M tests/vhost-user-test.c

  Log Message:
  -----------
  vhost-user-test: create a main loop per TestServer

This makes the tests more independent and removes the need to defer 
test_server_free
via an idle event source.

Reviewed-by: Marc-André Lureau <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 9ee1bb86f641bf6029a9c326d9d49ab6c5a7b380
      
https://github.com/qemu/qemu/commit/9ee1bb86f641bf6029a9c326d9d49ab6c5a7b380
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M tests/vhost-user-test.c

  Log Message:
  -----------
  vhost-user-test: small changes to init_hugepagefs

After the conversion to qgraph, the equivalent of "main" will be in
a constructor and will run even if the tests are not being requested.
Therefore, it should not assert that init_hugepagefs succeeds and will
be called when creating the TestServer.  This patch changes the prototype
of init_hugepagefs, this way the next patch looks nicer.

Reviewed-by: Marc-André Lureau <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 4d3f50eb489e783d08d047b3a9229f96ecdfd136
      
https://github.com/qemu/qemu/commit/4d3f50eb489e783d08d047b3a9229f96ecdfd136
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M tests/vhost-user-test.c

  Log Message:
  -----------
  vhost-user-test: create a temporary directory per TestServer

This makes the tests more independent, and also the source and destination
TestServers in the migration test.

Reviewed-by: Marc-André Lureau <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 23858f4092fc9ebf9e7a5e5110e44abef6fc6643
      
https://github.com/qemu/qemu/commit/23858f4092fc9ebf9e7a5e5110e44abef6fc6643
  Author: Laszlo Ersek <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M .gitmodules
    M Makefile
    A roms/edk2

  Log Message:
  -----------
  roms: add the edk2 project as a git submodule

The roms/edk2 submodule can help with three goals:
- build the OVMF and ArmVirtQemu virtual UEFI firmware platforms (to be
  implemented later),
- build the EfiRom tool on the fly, which is used in roms/Makefile, for
  building the "efirom" target,
- build UEFI test applications (to be run in guests), for qtest support.

Edk2 commit 85588389222a3636baf0f9ed8227f2434af4c3f9 stands for the latest
"stable tag", namely "edk2-stable201811".

The edk2 repository tracks some binary files that should not be removed by
QEMU's top-level "make clean"; exempt the full pathnames from the "find"
command.

Cc: "Michael S. Tsirkin" <address@hidden>
Cc: Ard Biesheuvel <address@hidden>
Cc: Gerd Hoffmann <address@hidden>
Cc: Igor Mammedov <address@hidden>
Cc: Philippe Mathieu-Daudé <address@hidden>
Cc: Shannon Zhao <address@hidden>
Signed-off-by: Laszlo Ersek <address@hidden>
Reviewed-by: Gerd Hoffmann <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>


  Commit: f590a812c21074e82228de3e1dfb57b75fc02b62
      
https://github.com/qemu/qemu/commit/f590a812c21074e82228de3e1dfb57b75fc02b62
  Author: Laszlo Ersek <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M roms/Makefile

  Log Message:
  -----------
  roms: build the EfiRom utility from the roms/edk2 submodule

Building the EfiRom utility from "roms/edk2/BaseTools" should make
"roms/Makefile" more self-contained. Otherwise, we'd call the system-wide
EfiRom for building the combined iPXE option ROMs, but call the sibling
utilities from "roms/edk2/BaseTools" for building "roms/edk2" content.

Cc: "Michael S. Tsirkin" <address@hidden>
Cc: Ard Biesheuvel <address@hidden>
Cc: Gerd Hoffmann <address@hidden>
Cc: Igor Mammedov <address@hidden>
Cc: Philippe Mathieu-Daudé <address@hidden>
Cc: Shannon Zhao <address@hidden>
Signed-off-by: Laszlo Ersek <address@hidden>
Reviewed-by: Gerd Hoffmann <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 09a274d82f13683e82a2930b5567f657297a987a
      
https://github.com/qemu/qemu/commit/09a274d82f13683e82a2930b5567f657297a987a
  Author: Laszlo Ersek <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    A tests/uefi-test-tools/LICENSE
    A tests/uefi-test-tools/UefiTestToolsPkg/BiosTablesTest/BiosTablesTest.c
    A tests/uefi-test-tools/UefiTestToolsPkg/BiosTablesTest/BiosTablesTest.inf
    A tests/uefi-test-tools/UefiTestToolsPkg/Include/Guid/BiosTablesTest.h
    A tests/uefi-test-tools/UefiTestToolsPkg/UefiTestToolsPkg.dec
    A tests/uefi-test-tools/UefiTestToolsPkg/UefiTestToolsPkg.dsc

  Log Message:
  -----------
  tests: introduce "uefi-test-tools" with the BiosTablesTest UEFI app

The "bios-tables-test" program in QEMU's test suite locates the RSD PTR
ACPI table in guest RAM, and (chasing pointers to other ACPI tables)
performs various sanity checks on the QEMU-generated and
firmware-installed tables.

Currently this set of test cases doesn't work with UEFI guests. The ACPI
spec defines distinct methods for OSPM to locate the RSD PTR on
traditional BIOS vs. UEFI platforms, and the UEFI method is more difficult
to implement from the hypervisor side with just raw guest memory access.

Add a UEFI application (to be booted in the UEFI guest) that populates a
small, MB-aligned structure in guest RAM. The structure begins with a
signature GUID. The hypervisor should loop over all MB-aligned pages in
guest RAM until one matches the signature GUID at offset 0, at which point
the hypervisor can fetch the RSDP address field(s) from the structure.

QEMU's test logic currently spins on a pre-determined guest address, until
that address assumes a magic value. The method described in this patch is
conceptually the same ("busy loop until match is found"), except there is
no hard-coded address. This plays a lot more nicely with UEFI guest
firmware (we'll be able to use the normal page allocation UEFI service).
Given the size of EFI_GUID (16 bytes -- 128 bits), mismatches should be
astronomically unlikely. In addition, given the typical guest RAM size for
such tests (128 MB), there are 128 locations to check in one iteration of
the "outer" loop, which shouldn't introduce an intolerable delay after the
guest stores the RSDP address(es), and then the GUID.

The GUID that the hypervisor should search for is

  AB87A6B1-2034-BDA0-71BD-375007757785

Expressed as a byte array:

 {
   0xb1, 0xa6, 0x87, 0xab,
   0x34, 0x20,
   0xa0, 0xbd,
   0x71, 0xbd, 0x37, 0x50, 0x07, 0x75, 0x77, 0x85
 }

Note that in the patch, we define "gBiosTablesTestGuid" with all bits
inverted. This is a simple method to prevent the UEFI binary, which
incorporates "gBiosTablesTestGuid", from matching the actual GUID in guest
RAM.

The UEFI application is written against the edk2 framework, which was
introduced earlier as a git submodule. The next patch will provide build
scripts for maintainers.

The source code follows the edk2 coding style, and is licensed under the
2-clause BSDL (in case someone would like to include UefiTestToolsPkg
content in a different edk2 platform).

The "UefiTestToolsPkg.dsc" platform description file resolves the used
edk2 library classes to instances (= library implementations) such that
the UEFI binaries inherit no platform dependencies. They are expected to
run on any system that conforms to the UEFI-2.3.1 spec (which was released
in 2012). The arch-specific build options are carried over from edk2's
ArmVirtPkg and OvmfPkg platforms.

Cc: "Michael S. Tsirkin" <address@hidden>
Cc: Ard Biesheuvel <address@hidden>
Cc: Gerd Hoffmann <address@hidden>
Cc: Igor Mammedov <address@hidden>
Cc: Philippe Mathieu-Daudé <address@hidden>
Cc: Shannon Zhao <address@hidden>
Signed-off-by: Laszlo Ersek <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 77db55fc81550c695f6fd75c3879ad59d002ab70
      
https://github.com/qemu/qemu/commit/77db55fc81550c695f6fd75c3879ad59d002ab70
  Author: Laszlo Ersek <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    A tests/uefi-test-tools/.gitignore
    A tests/uefi-test-tools/Makefile
    A tests/uefi-test-tools/build.sh

  Log Message:
  -----------
  tests/uefi-test-tools: add build scripts

Introduce the following build scripts under "tests/uefi-test-tools":

* "build.sh" builds a single module (a UEFI application) from
  UefiTestToolsPkg, for a single QEMU emulation target.

  "build.sh" relies on cross-compilers when the emulation target and the
  build host architecture don't match. The cross-compiler prefix is
  computed according to a fixed, Linux-specific pattern. No attempt is
  made to copy or reimplement the GNU Make magic from "qemu/roms/Makefile"
  for cross-compiler prefix determination. The reason is that the build
  host OSes that are officially supported by edk2, and those that are
  supported by QEMU, intersect only in Linux. (Note that the UNIXGCC
  toolchain is being removed from edk2,
  <https://bugzilla.tianocore.org/show_bug.cgi?id=1377>.)

* "Makefile" currently builds the "UefiTestToolsPkg/BiosTablesTest"
  application, for arm, aarch64, i386, and x86_64, with the help of
  "build.sh".

  "Makefile" turns each resultant UEFI executable into a UEFI-bootable,
  qcow2-compressed ISO image. The ISO images are output as
  "tests/data/uefi-boot-images/bios-tables-test.<TARGET>.iso.qcow2".

  Each ISO image should be passed to QEMU as follows:

    -drive id=boot-cd,if=none,readonly,format=qcow2,file=$ISO \
    -device virtio-scsi-pci,id=scsi0 \
    -device scsi-cd,drive=boot-cd,bus=scsi0.0,bootindex=0 \

  "Makefile" assumes that "mkdosfs", "mtools", and "genisoimage" are
  present.

Cc: "Michael S. Tsirkin" <address@hidden>
Cc: Ard Biesheuvel <address@hidden>
Cc: Gerd Hoffmann <address@hidden>
Cc: Igor Mammedov <address@hidden>
Cc: Philippe Mathieu-Daudé <address@hidden>
Cc: Shannon Zhao <address@hidden>
Signed-off-by: Laszlo Ersek <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 503bb0b975ab8916256fe0080722ab8a64f29e1b
      
https://github.com/qemu/qemu/commit/503bb0b975ab8916256fe0080722ab8a64f29e1b
  Author: Laszlo Ersek <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    A tests/data/uefi-boot-images/bios-tables-test.aarch64.iso.qcow2
    A tests/data/uefi-boot-images/bios-tables-test.arm.iso.qcow2
    A tests/data/uefi-boot-images/bios-tables-test.i386.iso.qcow2
    A tests/data/uefi-boot-images/bios-tables-test.x86_64.iso.qcow2

  Log Message:
  -----------
  tests/data: introduce "uefi-boot-images" with the "bios-tables-test" ISOs

Add UEFI-bootable qcow2-compressed ISO images built from:

  tests/uefi-test-tools/UefiTestToolsPkg/BiosTablesTest

Cc: "Michael S. Tsirkin" <address@hidden>
Cc: Ard Biesheuvel <address@hidden>
Cc: Gerd Hoffmann <address@hidden>
Cc: Igor Mammedov <address@hidden>
Cc: Philippe Mathieu-Daudé <address@hidden>
Cc: Shannon Zhao <address@hidden>
Signed-off-by: Laszlo Ersek <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: f60f5e8076b7420e720def514b84f366766beed1
      
https://github.com/qemu/qemu/commit/f60f5e8076b7420e720def514b84f366766beed1
  Author: Wei Yang <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M hw/mem/pc-dimm.c

  Log Message:
  -----------
  pc-dimm: use same mechanism for [get|set]_addr

[get|set]_addr are two counterpart to access PCDIMMDevice.addr.

Since we have already set up a property PC_DIMM_ADDR_PROP for this
field and use this mechanism in set_addr, it would be more proper to use
the same mechanism in get_addr.

This patch uses object_property_get_uint() to replace the direct memory
access to make [get|set]_addr with the same mechanism.

Signed-off-by: Wei Yang <address@hidden>

Message-Id: <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 8c43812ba2bcf7ca11002f6f0e60931f8179d439
      
https://github.com/qemu/qemu/commit/8c43812ba2bcf7ca11002f6f0e60931f8179d439
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M contrib/vhost-user-blk/vhost-user-blk.c
    M target/i386/kvm.c

  Log Message:
  -----------
  Revert "contrib/vhost-user-blk: fix the compilation issue"

Commit a56de056c91f8 squashed the following two unrelated commits
at once:

- "contrib/vhost-user-blk: fix the compilation issue"
  (Message-Id: address@hidden)
- "i386/kvm: ignore masked irqs when update msi routes"
  (Message-Id: address@hidden)

While the git history remains bisectable, having a commit that changes
MSI/MSIX code but describes it as "fix vhost-user-blk compilation" is
rather confusing.
Revert the offending commit to properly apply both patches separately.

Reported-by: Peter Xu <address@hidden>
Fixes: a56de056c91f8
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Peter Xu <address@hidden>


  Commit: 4387b78ac31279cd575658d02fcea26e743a1c79
      
https://github.com/qemu/qemu/commit/4387b78ac31279cd575658d02fcea26e743a1c79
  Author: Changpeng Liu <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M contrib/vhost-user-blk/vhost-user-blk.c

  Log Message:
  -----------
  contrib/vhost-user-blk: fix the compilation issue

Signed-off-by: Changpeng Liu <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Stefano Garzarella <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Message-Id: <address@hidden>
[PMD: this patch was first (incorrectly) introduced as a56de056c91f8]
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Peter Xu <address@hidden>


  Commit: 558e8c6139a5f517433b6f1779b2df8a0b4ff610
      
https://github.com/qemu/qemu/commit/558e8c6139a5f517433b6f1779b2df8a0b4ff610
  Author: Peter Xu <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

  Changed paths:
    M target/i386/kvm.c

  Log Message:
  -----------
  i386/kvm: ignore masked irqs when update msi routes

When we are with intel-iommu device and with IR on, KVM will register
an IEC notifier to detect interrupt updates from the guest and we'll
kick off kvm_update_msi_routes_all() when it happens to make sure
kernel IRQ cache is matching the latest.

Though, kvm_update_msi_routes_all() is buggy in that it ignored the
mask bit of either MSI/MSIX messages and it tries to translate the
message even if the corresponding message was already masked by the
guest driver (hence the MSI/MSIX message will be invalid).

Without this patch, we can receive an error message when we reboot a
guest with both an assigned vfio-pci device and intel-iommu enabled:

  qemu-system-x86_64: vtd_interrupt_remap_msi: MSI address low 32 bit invalid: 
0x0

The error does not affect functionality of the guest since when we
failed to translate we'll just silently continue (which makes sense
since crashing the VM for this seems even worse), but still it's
better to fix it up.

Signed-off-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Message-Id: <address@hidden>
[PMD: this patch was first (incorrectly) introduced as a56de056c91f8]
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Peter Xu <address@hidden>


  Commit: f6deb6d95aa7c29fa0047057512060ca720cad22
      
https://github.com/qemu/qemu/commit/f6deb6d95aa7c29fa0047057512060ca720cad22
  Author: David Gibson <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

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

  Log Message:
  -----------
  virtio-balloon: Remove unnecessary MADV_WILLNEED on deflate

When the balloon is inflated, we discard memory place in it using madvise()
with MADV_DONTNEED.  And when we deflate it we use MADV_WILLNEED, which
sounds like it makes sense but is actually unnecessary.

The misleadingly named MADV_DONTNEED just discards the memory in question,
it doesn't set any persistent state on it in-kernel; all that's necessary
to bring the memory back is to touch it.  MADV_WILLNEED in contrast
specifically says that the memory will be used soon and faults it in.

This patch simplify's the balloon operation by dropping the madvise()
on deflate.  This might have an impact on performance - it will move a
delay at deflate time until that memory is actually touched, which
might be more latency sensitive.  However:

  * Memory that's being given back to the guest by deflating the
    balloon *might* be used soon, but it equally could just sit around
    in the guest's pools until needed (or even be faulted out again if
    the host is under memory pressure).

  * Usually, the timescale over which you'll be adjusting the balloon
    is long enough that a few extra faults after deflation aren't
    going to make a difference.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: b218a70e6ae882f52cc339ae965f515a36a9139f
      
https://github.com/qemu/qemu/commit/b218a70e6ae882f52cc339ae965f515a36a9139f
  Author: David Gibson <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

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

  Log Message:
  -----------
  virtio-balloon: Corrections to address verification

The virtio-balloon device's verification of the address given to it by the
guest has a number of faults:
    * The addresses here are guest physical addresses, which should be
      'hwaddr' rather than 'ram_addr_t' (the distinction is admittedly
      pretty subtle and confusing)
    * We don't check for section.mr being NULL, which is the main way that
      memory_region_find() reports basic failures.  We really need to check
      that before looking at any other section fields, because
      memory_region_find() doesn't initialize them on the failure path
    * We're passing a length of '1' to memory_region_find(), but really the
      guest is requesting that we put the entire page into the balloon,
      so it makes more sense to call it with BALLOON_PAGE_SIZE

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: e9550234d79ddb69b01721d8cb197edc0a14a245
      
https://github.com/qemu/qemu/commit/e9550234d79ddb69b01721d8cb197edc0a14a245
  Author: David Gibson <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

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

  Log Message:
  -----------
  virtio-balloon: Rework ballon_page() interface

This replaces the balloon_page() internal interface with
ballon_inflate_page(), with a slightly different interface.  The new
interface will make future alterations simpler.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: dbe1a2774521d838c34b831d89a4bb646a8e9d7c
      
https://github.com/qemu/qemu/commit/dbe1a2774521d838c34b831d89a4bb646a8e9d7c
  Author: David Gibson <address@hidden>
  Date:   2019-02-21 (Thu, 21 Feb 2019)

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

  Log Message:
  -----------
  virtio-balloon: Use ram_block_discard_range() instead of raw madvise()

Currently, virtio-balloon uses madvise() with MADV_DONTNEED to actually
discard RAM pages inserted into the balloon.  This is basically a Linux
only interface (MADV_DONTNEED exists on some other platforms, but doesn't
always have the same semantics).  It also doesn't work on hugepages and has
some other limitations.

It turns out that postcopy also needs to discard chunks of memory, and uses
a better interface for it: ram_block_discard_range().  It doesn't cover
every case, but it covers more than going direct to madvise() and this
gives us a single place to update for more possibilities in future.

There are some subtleties here to maintain the current balloon behaviour:

* For now, we just ignore requests to balloon in a hugepage backed region.
  That matches current behaviour, because MADV_DONTNEED on a hugepage would
  simply fail, and we ignore the error.

* If host page size is > BALLOON_PAGE_SIZE we can frequently call this on
  non-host-page-aligned addresses.  These would also fail in madvise(),
  which we then ignored.  ram_block_discard_range() error_report()s calls
  on unaligned addresses, so we explicitly check that case to avoid
  spamming the logs.

* We now call ram_block_discard_range() with the *host* page size, whereas
  we previously called madvise() with BALLOON_PAGE_SIZE.  Surprisingly,
  this also matches existing behaviour.  Although the kernel fails madvise
  on unaligned addresses, it will round unaligned sizes *up* to the host
  page size.  Yes, this means that if BALLOON_PAGE_SIZE < guest page size
  we can incorrectly discard more memory than the guest asked us to.  I'm
  planning to address that soon.

Errors other than the ones discussed above, will now be reported by
ram_block_discard_range(), rather than silently ignored, which means we
have a much better chance of seeing when something is going wrong.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: ed48c59875b603058366490f472490f0fb9c30f3
      
https://github.com/qemu/qemu/commit/ed48c59875b603058366490f472490f0fb9c30f3
  Author: David Gibson <address@hidden>
  Date:   2019-02-22 (Fri, 22 Feb 2019)

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

  Log Message:
  -----------
  virtio-balloon: Safely handle BALLOON_PAGE_SIZE < host page size

The virtio-balloon always works in units of 4kiB (BALLOON_PAGE_SIZE), but
we can only actually discard memory in units of the host page size.

Now, we handle this very badly: we silently ignore balloon requests that
aren't host page aligned, and for requests that are host page aligned we
discard the entire host page.  The latter can corrupt guest memory if its
page size is smaller than the host's.

The obvious choice would be to disable the balloon if the host page size is
not 4kiB.  However, that would break the special case where host and guest
have the same page size, but that's larger than 4kiB.  That case currently
works by accident[1] - and is used in practice on many production POWER
systems where 64kiB has long been the Linux default page size on both host
and guest.

To make the balloon safe, without breaking that useful special case, we
need to accumulate 4kiB balloon requests until we have a whole contiguous
host page to discard.

We could in principle do that across all guest memory, but it would require
a large bitmap to track.  This patch represents a compromise: we track
ballooned subpages for a single contiguous host page at a time.  This means
that if the guest discards all 4kiB chunks of a host page in succession,
we will discard it.  This is the expected behaviour in the (host page) ==
(guest page) != 4kiB case we want to support.

If the guest scatters 4kiB requests across different host pages, we don't
discard anything, and issue a warning.  Not ideal, but at least we don't
corrupt guest memory as the previous version could.

Warning reporting is kind of a compromise here.  Determining whether we're
in a problematic state at realize() time is tricky, because we'd have to
look at the host pagesizes of all memory backends, but we can't really know
if some of those backends could be for special purpose memory that's not
subject to ballooning.

Reporting only when the guest tries to balloon a partial page also isn't
great because if the guest page size happens to line up it won't indicate
that we're in a non ideal situation.  It could also cause alarming repeated
warnings whenever a migration is attempted.

So, what we do is warn the first time the guest attempts balloon a partial
host page, whether or not it will end up ballooning the rest of the page
immediately afterwards.

[1] Because when the guest attempts to balloon a page, it will submit
    requests for each 4kiB subpage.  Most will be ignored, but the one
    which happens to be host page aligned will discard the whole lot.

Signed-off-by: David Gibson <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: ee1cd0099ab04f748c6d839e4f4d9a41b21e7399
      
https://github.com/qemu/qemu/commit/ee1cd0099ab04f748c6d839e4f4d9a41b21e7399
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2019-02-22 (Fri, 22 Feb 2019)

  Changed paths:
    M hw/vfio/pci-quirks.c
    M include/hw/pci/pci_ids.h

  Log Message:
  -----------
  pci: Move NVIDIA vendor id to the rest of ids

sPAPR code will use it too so move it from VFIO to the common code.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Reviewed-by: Alistair Francis <address@hidden>
Message-Id: <address@hidden>
Acked-by: Alex Williamson <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: b81a5f9427270133c27ab660c0054b277b2728d7
      
https://github.com/qemu/qemu/commit/b81a5f9427270133c27ab660c0054b277b2728d7
  Author: Daniel P. Berrangé <address@hidden>
  Date:   2019-02-22 (Fri, 22 Feb 2019)

  Changed paths:
    M hw/smbios/smbios.c
    M include/hw/firmware/smbios.h

  Log Message:
  -----------
  hw/smbios: fix offset of type 3 sku field

The type 3 SMBIOS structure[1] ends with fields

  ...
  0x14  - contained element count
  0x15  - contained element record length
  0x16  - sku number

The smbios_type_3 struct missed the contained element record
length field, causing sku number to be reported at the wrong
offset.

[1] 
https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.1.1.pdf

Signed-off-by: Daniel P. Berrangé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Fixes: e41fca3da72
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 88c869198aa630e0477d653d0abf3f42c7c44d1f
      
https://github.com/qemu/qemu/commit/88c869198aa630e0477d653d0abf3f42c7c44d1f
  Author: Alex Williamson <address@hidden>
  Date:   2019-02-22 (Fri, 22 Feb 2019)

  Changed paths:
    M hw/pci/pcie.c

  Log Message:
  -----------
  pci: Sanity test minimum downstream LNKSTA

The entire link status register for SR-IOV VFs is defined as RsvdZ,
reads simply return zero.  Usually this is nothing more than lspci
reporting inconsequentially broken values:

    LnkSta: Speed unknown, Width x0, ...

However, now that we're using the downstream endpoint link status to
fill in the value at the parent downstream port, invalid values become
a problem.  In particular, the PCIe hotplug driver in Linux looks for
a valid negotiated link width and will fail to enumerate hot-added
downstream endpoints without non-zero value here, ex:

    pciehp 0000:00:02.0:pcie004: Slot(0): Attention button pressed
    pciehp 0000:00:02.0:pcie004: Slot(0) Powering on due to button press
    pciehp 0000:00:02.0:pcie004: Slot(0): Card present
    pciehp 0000:00:02.0:pcie004: Slot(0): Link Up
    pciehp 0000:00:02.0:pcie004: link training error: status 0x2000
    pciehp 0000:00:02.0:pcie004: Failed to check link status

Resolve by using minimum width and speed values for the downstream
port link status when the endpoint fails to provide valid values.
Long term, we may want to implement emulation in the vfio-pci host
driver to suppliment this field with the PF value as the SR-IOV spec
seems to allow, but the solution here is compatible should that be
implemented later.

Fixes: 727b48661f75 ("pci: Sync PCIe downstream port LNKSTA on read")
Reported-by: Jens Freimann <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>
Message-Id: <address@hidden>
Tested-by: Jens Freimann <address@hidden>
Reviewed-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>


  Commit: 1d31f1872b337e4acac5bf6b3c2a45b66e43b494
      
https://github.com/qemu/qemu/commit/1d31f1872b337e4acac5bf6b3c2a45b66e43b494
  Author: Peter Maydell <address@hidden>
  Date:   2019-03-04 (Mon, 04 Mar 2019)

  Changed paths:
    M .gitmodules
    M Makefile
    M backends/Makefile.objs
    M configure
    M default-configs/virtio.mak
    M hw/mem/pc-dimm.c
    M hw/net/Makefile.objs
    A hw/net/vhost_net-stub.c
    M hw/net/vhost_net.c
    M hw/pci/pcie.c
    M hw/smbios/smbios.c
    M hw/vfio/pci-quirks.c
    M hw/virtio/Makefile.objs
    M hw/virtio/vhost-backend.c
    M hw/virtio/vhost-user.c
    M hw/virtio/vhost.c
    M hw/virtio/virtio-balloon.c
    M include/exec/poison.h
    M include/hw/firmware/smbios.h
    M include/hw/pci/pci_ids.h
    M include/hw/virtio/virtio-balloon.h
    M net/Makefile.objs
    M net/net.c
    A net/vhost-user-stub.c
    M net/vhost-user.c
    M roms/Makefile
    A roms/edk2
    M tests/Makefile.include
    A tests/data/uefi-boot-images/bios-tables-test.aarch64.iso.qcow2
    A tests/data/uefi-boot-images/bios-tables-test.arm.iso.qcow2
    A tests/data/uefi-boot-images/bios-tables-test.i386.iso.qcow2
    A tests/data/uefi-boot-images/bios-tables-test.x86_64.iso.qcow2
    A tests/uefi-test-tools/.gitignore
    A tests/uefi-test-tools/LICENSE
    A tests/uefi-test-tools/Makefile
    A tests/uefi-test-tools/UefiTestToolsPkg/BiosTablesTest/BiosTablesTest.c
    A tests/uefi-test-tools/UefiTestToolsPkg/BiosTablesTest/BiosTablesTest.inf
    A tests/uefi-test-tools/UefiTestToolsPkg/Include/Guid/BiosTablesTest.h
    A tests/uefi-test-tools/UefiTestToolsPkg/UefiTestToolsPkg.dec
    A tests/uefi-test-tools/UefiTestToolsPkg/UefiTestToolsPkg.dsc
    A tests/uefi-test-tools/build.sh
    M tests/vhost-user-test.c

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

pci, pc, virtio: fixes, cleanups, tests

Lots of work on tests: BiosTablesTest UEFI app,
vhost-user testing for non-Linux hosts.
Misc cleanups and fixes all over the place

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

# gpg: Signature made Fri 22 Feb 2019 15:51:40 GMT
# gpg:                using RSA key 281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <address@hidden>" [full]
# gpg:                 aka "Michael S. Tsirkin <address@hidden>" [full]
# 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: (26 commits)
  pci: Sanity test minimum downstream LNKSTA
  hw/smbios: fix offset of type 3 sku field
  pci: Move NVIDIA vendor id to the rest of ids
  virtio-balloon: Safely handle BALLOON_PAGE_SIZE < host page size
  virtio-balloon: Use ram_block_discard_range() instead of raw madvise()
  virtio-balloon: Rework ballon_page() interface
  virtio-balloon: Corrections to address verification
  virtio-balloon: Remove unnecessary MADV_WILLNEED on deflate
  i386/kvm: ignore masked irqs when update msi routes
  contrib/vhost-user-blk: fix the compilation issue
  Revert "contrib/vhost-user-blk: fix the compilation issue"
  pc-dimm: use same mechanism for [get|set]_addr
  tests/data: introduce "uefi-boot-images" with the "bios-tables-test" ISOs
  tests/uefi-test-tools: add build scripts
  tests: introduce "uefi-test-tools" with the BiosTablesTest UEFI app
  roms: build the EfiRom utility from the roms/edk2 submodule
  roms: add the edk2 project as a git submodule
  vhost-user-test: create a temporary directory per TestServer
  vhost-user-test: small changes to init_hugepagefs
  vhost-user-test: create a main loop per TestServer
  ...

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


Compare: https://github.com/qemu/qemu/compare/20b084c4b140...1d31f1872b33
[Prev in Thread]
Current Thread
[Next in Thread]
[Qemu-commits] [qemu/qemu] 7b28c6: vhost-net: move stubs to a separate file, Peter Maydell <=
Prev by Date: [Qemu-commits] [qemu/qemu] 93198b: i2c: Split smbus into parts
Next by Date: [Qemu-commits] [qemu/qemu] 2cca53: s390x: Use cpu_to_be64 in SIGP STORE ADDITIONAL ST...
Previous by thread: [Qemu-commits] [qemu/qemu] 93198b: i2c: Split smbus into parts
Next by thread: [Qemu-commits] [qemu/qemu] 2cca53: s390x: Use cpu_to_be64 in SIGP STORE ADDITIONAL ST...
Index(es):
- Date
- Thread