qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] e36828: qom: assert integer does not overflow


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] e36828: qom: assert integer does not overflow
Date: Fri, 04 Mar 2022 10:43:37 -0800

  Branch: refs/heads/staging
  Home:   https://github.com/qemu/qemu
  Commit: e36828787f2c35df64448f4142169ef5e193f5b3
      
https://github.com/qemu/qemu/commit/e36828787f2c35df64448f4142169ef5e193f5b3
  Author: Michael S. Tsirkin <mst@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M qom/object.c

  Log Message:
  -----------
  qom: assert integer does not overflow

QOM reference counting is not designed with an infinite amount of
references in mind, trying to take a reference in a loop without
dropping a reference will overflow the integer.

It is generally a symptom of a reference leak (a missing deref, commonly
as part of error handling - such as one fixed here:
https://lore.kernel.org/r/20220228095058.27899-1-sgarzare%40redhat.com ).

All this can lead to either freeing the object too early (memory
corruption) or never freeing it (memory leak).

If we happen to dereference at just the right time (when it's wrapping
around to 0), we might eventually assert when dereferencing, but the
real problem is an extra object_ref so let's assert there to make such
issues cleaner and easier to debug.

Some micro-benchmarking shows using fetch and add this is essentially
free on x86.

Since multiple threads could be incrementing in parallel, we assert
around INT_MAX to make sure none of these approach the wrap around
point: this way we get a memory leak and not a memory corruption, the
former is generally easier to debug.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 0ef0506e559612edd10fe45dfd2f349c224601a1
      
https://github.com/qemu/qemu/commit/0ef0506e559612edd10fe45dfd2f349c224601a1
  Author: Eric DeVolder <eric.devolder@oracle.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    A docs/specs/acpi_erst.rst
    M docs/specs/index.rst

  Log Message:
  -----------
  ACPI ERST: specification for ERST support

Information on the implementation of the ACPI ERST support.

Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Acked-by: Ani Sinha <ani@anisinha.ca>
Message-Id: <20220223143322.927136-2-ani@anisinha.ca>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 2a06afec1f72577cfa4509066abf3cc88f22a97d
      
https://github.com/qemu/qemu/commit/2a06afec1f72577cfa4509066abf3cc88f22a97d
  Author: Ani Sinha <ani@anisinha.ca>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M MAINTAINERS

  Log Message:
  -----------
  MAINTAINERS: no need to add my name explicitly as a reviewer for VIOT tables

I am already listed as a reviewer for ACPI/SMBIOS subsystem. There is no need to
again add me as a reviewer for ACPI/VIOT.

Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Message-Id: <20220223143322.927136-3-ani@anisinha.ca>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 1665b4d51036b9c92bdd8da507beffb9cc417aa7
      
https://github.com/qemu/qemu/commit/1665b4d51036b9c92bdd8da507beffb9cc417aa7
  Author: Ani Sinha <ani@anisinha.ca>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M docs/specs/pci-ids.txt

  Log Message:
  -----------
  docs/acpi/erst: add device id for ACPI ERST device in pci-ids.txt

Adding device ID for ERST device in pci-ids.txt. It was missed when ERST
related patches were reviewed.

CC: Eric DeVolder <eric.devolder@oracle.com>
Reviewed-by: Eric DeVolder <eric.devolder@oracle.com>
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Message-Id: <20220223143322.927136-4-ani@anisinha.ca>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: f8bdfbdba9082f20b414fe0b768c4e2882b31059
      
https://github.com/qemu/qemu/commit/f8bdfbdba9082f20b414fe0b768c4e2882b31059
  Author: Ani Sinha <ani@anisinha.ca>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/acpi/erst.c

  Log Message:
  -----------
  hw/acpi/erst: clean up unused IS_UEFI_CPER_RECORD macro

This change is cosmetic. IS_UEFI_CPER_RECORD macro definition that was added
as a part of the ERST implementation seems to be unused. Remove it.

CC: Eric DeVolder <eric.devolder@oracle.com>
Reviewed-by: Eric DeVolder <eric.devolder@oracle.com>
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Message-Id: <20220223143322.927136-5-ani@anisinha.ca>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 3818acf56480ae07f8801f9255b82fe587ef39c1
      
https://github.com/qemu/qemu/commit/3818acf56480ae07f8801f9255b82fe587ef39c1
  Author: Ani Sinha <ani@anisinha.ca>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/smbios/smbios.c

  Log Message:
  -----------
  hw/smbios: code cleanup - use macro definitions for table header handles

This is a minor cleanup. Using macro definitions makes the code more
readable. It is at once clear which tables use which handle numbers in their
header. It also makes it easy to calculate the gaps between the numbers and
update them if needed.

Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Message-Id: <20220223143322.927136-6-ani@anisinha.ca>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>


  Commit: a379d4550c4a949bb1ca51bc5272d68b4a619b18
      
https://github.com/qemu/qemu/commit/a379d4550c4a949bb1ca51bc5272d68b4a619b18
  Author: Ani Sinha <ani@anisinha.ca>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/smbios/smbios.c

  Log Message:
  -----------
  hw/smbios: fix overlapping table handle numbers with large memory vms

The current smbios table implementation splits the main memory in 16 GiB
(DIMM like) chunks. With the current smbios table assignment code, we can have
only 512 such chunks before the 16 bit handle numbers in the header for tables
17 and 19 conflict. A guest with more than 8 TiB of memory will hit this
limitation and would fail with the following assertion in isa-debugcon:

ASSERT_EFI_ERROR (Status = Already started)
ASSERT 
/builddir/build/BUILD/edk2-ca407c7246bf/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c(125):
 !EFI_ERROR (Status)

This change adds an additional offset between tables 17 and 19 handle numbers
when configuring VMs larger than 8 TiB of memory. The value of the offset is
calculated to be equal to the additional space required to be reserved
in order to accomodate more DIMM entries without the table handles colliding.
In normal cases where the VM memory is smaller or equal to 8 TiB, this offset
value is 0. Hence in this case, no additional handle numbers are reserved and
table handle values remain as before.

Since smbios memory is not transmitted over the wire during migration,
this change can break migration for large memory vms if the guest is in the
middle of generating the tables during migration. However, in those
situations, qemu generates invalid table handles anyway with or without this
fix. Hence, we do not preserve the old bug by introducing compat knobs/machine
types.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2023977

Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220223143322.927136-7-ani@anisinha.ca>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 63670bd3fce3d0c033d939d1b2b7a5f6834d0cf3
      
https://github.com/qemu/qemu/commit/63670bd3fce3d0c033d939d1b2b7a5f6834d0cf3
  Author: Ani Sinha <ani@anisinha.ca>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/smbios/smbios.c

  Log Message:
  -----------
  hw/smbios: add assertion to ensure handles of tables 19 and 32 do not collide

Since change dcf359832eec02 ("hw/smbios: fix table memory corruption with large 
memory vms")
we reserve additional space between handle numbers of tables 17 and 19 for
large VMs. This may cause table 19 to collide with table 32 in their handle
numbers for those large VMs. This change adds an assertion to ensure numbers
do not collide. If they do, qemu crashes with useful debug information for
taking additional steps.

Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220223143322.927136-8-ani@anisinha.ca>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: e867144b73b3c5009266b6df07d5ff44acfb82c3
      
https://github.com/qemu/qemu/commit/e867144b73b3c5009266b6df07d5ff44acfb82c3
  Author: Xueming Li <xuemingl@nvidia.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

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

  Log Message:
  -----------
  vhost-user: remove VirtQ notifier restore

Notifier set when vhost-user backend asks qemu to mmap an FD and
offset. When vhost-user backend restart or getting killed, VQ notifier
FD and mmap addresses become invalid. After backend restart, MR contains
the invalid address will be restored and fail on notifier access.

On the other hand, qemu should munmap the notifier, release underlying
hardware resources to enable backend restart and allocate hardware
notifier resources correctly.

Qemu shouldn't reference and use resources of disconnected backend.

This patch removes VQ notifier restore, uses the default vhost-user
notifier to avoid invalid address access.

After backend restart, the backend should ask qemu to install a hardware
notifier if needed.

Fixes: 44866521bd6e ("vhost-user: support registering external host notifiers")
Cc: qemu-stable@nongnu.org
Signed-off-by: Xueming Li <xuemingl@nvidia.com>
Message-Id: <20220207071929.527149-2-xuemingl@nvidia.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 0b0af4d62f7002b31cd7b2762b26d2fcb76bb2ba
      
https://github.com/qemu/qemu/commit/0b0af4d62f7002b31cd7b2762b26d2fcb76bb2ba
  Author: Xueming Li <xuemingl@nvidia.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

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

  Log Message:
  -----------
  vhost-user: fix VirtQ notifier cleanup

When vhost-user device cleanup, remove notifier MR and munmaps notifier
address in the event-handling thread, VM CPU thread writing the notifier
in concurrent fails with an error of accessing invalid address. It
happens because MR is still being referenced and accessed in another
thread while the underlying notifier mmap address is being freed and
becomes invalid.

This patch calls RCU and munmap notifiers in the callback after the
memory flatview update finish.

Fixes: 44866521bd6e ("vhost-user: support registering external host notifiers")
Cc: qemu-stable@nongnu.org
Signed-off-by: Xueming Li <xuemingl@nvidia.com>
Message-Id: <20220207071929.527149-3-xuemingl@nvidia.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: e65902a913bf31ba79a83a3bd3621108b85cf645
      
https://github.com/qemu/qemu/commit/e65902a913bf31ba79a83a3bd3621108b85cf645
  Author: Halil Pasic <pasic@linux.ibm.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

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

  Log Message:
  -----------
  virtio: fix the condition for iommu_platform not supported

The commit 04ceb61a40 ("virtio: Fail if iommu_platform is requested, but
unsupported") claims to fail the device hotplug when iommu_platform
is requested, but not supported by the (vhost) device. On the first
glance the condition for detecting that situation looks perfect, but
because a certain peculiarity of virtio_platform it ain't.

In fact the aforementioned commit introduces a regression. It breaks
virtio-fs support for Secure Execution, and most likely also for AMD SEV
or any other confidential guest scenario that relies encrypted guest
memory.  The same also applies to any other vhost device that does not
support _F_ACCESS_PLATFORM.

The peculiarity is that iommu_platform and _F_ACCESS_PLATFORM collates
"device can not access all of the guest RAM" and "iova != gpa, thus
device needs to translate iova".

Confidential guest technologies currently rely on the device/hypervisor
offering _F_ACCESS_PLATFORM, so that, after the feature has been
negotiated, the guest  grants access to the portions of memory the
device needs to see. So in for confidential guests, generally,
_F_ACCESS_PLATFORM is about the restricted access to memory, but not
about the addresses used being something else than guest physical
addresses.

This is the very reason for which commit f7ef7e6e3b ("vhost: correctly
turn on VIRTIO_F_IOMMU_PLATFORM") fences _F_ACCESS_PLATFORM from the
vhost device that does not need it, because on the vhost interface it
only means "I/O address translation is needed".

This patch takes inspiration from f7ef7e6e3b ("vhost: correctly turn on
VIRTIO_F_IOMMU_PLATFORM"), and uses the same condition for detecting the
situation when _F_ACCESS_PLATFORM is requested, but no I/O translation
by the device, and thus no device capability is needed. In this
situation claiming that the device does not support iommu_plattform=on
is counter-productive. So let us stop doing that!

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Reported-by: Jakob Naucke <Jakob.Naucke@ibm.com>
Fixes: 04ceb61a40 ("virtio: Fail if iommu_platform is requested, but
unsupported")
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-stable@nongnu.org

Message-Id: <20220207112857.607829-1-pasic@linux.ibm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>


  Commit: 0a24dd1fd50582cfbcac191cd24ccad48f6d2478
      
https://github.com/qemu/qemu/commit/0a24dd1fd50582cfbcac191cd24ccad48f6d2478
  Author: Viresh Kumar <viresh.kumar@linaro.org>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-user-i2c.c
    M include/hw/virtio/vhost-user-i2c.h

  Log Message:
  -----------
  hw/vhost-user-i2c: Add support for VIRTIO_I2C_F_ZERO_LENGTH_REQUEST

VIRTIO_I2C_F_ZERO_LENGTH_REQUEST is a mandatory feature, that must be
implemented by everyone. Add its support.

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: 
<fc47ab63b1cd414319c9201e8d6c7705b5ec3bd9.1644490993.git.viresh.kumar@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 8612355178a526d97c076937dea6cefbd58e3698
      
https://github.com/qemu/qemu/commit/8612355178a526d97c076937dea6cefbd58e3698
  Author: Eric Auger <eric.auger@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M tests/qtest/libqos/pci-pc.c
    M tests/qtest/libqos/pci-spapr.c
    M tests/qtest/libqos/pci.c
    M tests/qtest/libqos/pci.h

  Log Message:
  -----------
  tests/qtest/libqos/pci: Introduce pio_limit

At the moment the IO space limit is hardcoded to
QPCI_PIO_LIMIT = 0x10000. When accesses are performed to a bar,
the base address of this latter is compared against the limit
to decide whether we perform an IO or a memory access.

On ARM, we cannot keep this PIO limit as the arm-virt machine
uses [0x3eff0000, 0x3f000000 ] for the IO space map and we
are mandated to allocate at 0x0.

Add a new flag in QPCIBar indicating whether it is an IO bar
or a memory bar. This flag is set on QPCIBar allocation and
provisionned based on the BAR configuration. Then the new flag
is used in access functions and in iomap() function.

Signed-off-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20220210145254.157790-3-eric.auger@redhat.com>
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>


  Commit: 5499280f7998f112a44a2dda07bdeeb28a975b57
      
https://github.com/qemu/qemu/commit/5499280f7998f112a44a2dda07bdeeb28a975b57
  Author: Eric Auger <eric.auger@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M tests/qtest/e1000e-test.c
    M tests/qtest/libqos/pci.h
    M tests/qtest/vhost-user-blk-test.c
    M tests/qtest/virtio-blk-test.c
    M tests/qtest/virtio-net-test.c
    M tests/qtest/virtio-rng-test.c

  Log Message:
  -----------
  tests/qtest/libqos: Skip hotplug tests if pci root bus is not hotpluggable

ARM does not not support hotplug on pcie.0. Add a flag on the bus
which tells if devices can be hotplugged and skip hotplug tests
if the bus cannot be hotplugged. This is a temporary solution to
enable the other pci tests on aarch64.

Signed-off-by: Eric Auger <eric.auger@redhat.com>
Acked-by: Thomas Huth <thuth@redhat.com>

Message-Id: <20220210145254.157790-4-eric.auger@redhat.com>
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Acked-by: Thomas Huth <thuth@redhat.com>


  Commit: 20c2920dada7feb38fb664987bfbf0e93039faf2
      
https://github.com/qemu/qemu/commit/20c2920dada7feb38fb664987bfbf0e93039faf2
  Author: Eric Auger <eric.auger@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

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

  Log Message:
  -----------
  tests/qtest/vhost-user-blk-test: Temporary hack to get tests passing on 
aarch64

When run on ARM, basic and indirect tests currently fail with the
following error:

ERROR:../tests/qtest/libqos/virtio.c:224:qvirtio_wait_used_elem:
assertion failed (got_desc_idx == desc_idx): (50331648 == 0)
Bail out! ERROR:../tests/qtest/libqos/virtio.c:224: qvirtio_wait_used_elem:
assertion failed (got_desc_idx == desc_idx): (50331648 == 0)

I noticed it worked when I set up MSI and I further reduced the
code to a simple guest_alloc() that removes the error. At the moment
I am not able to identify where ths issue is and this blocks the
whole pci/aarch64 enablement.

Signed-off-by: Eric Auger <eric.auger@redhat.com>
Message-Id: <20220210145254.157790-5-eric.auger@redhat.com>
Signed-off-by: Eric Auger <eric.auger@redhat.com>


  Commit: ca3e537bd6a3abcb8cff0268f2cfa74f6b312f86
      
https://github.com/qemu/qemu/commit/ca3e537bd6a3abcb8cff0268f2cfa74f6b312f86
  Author: Eric Auger <eric.auger@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M tests/qtest/libqos/arm-virt-machine.c
    A tests/qtest/libqos/generic-pcihost.c
    A tests/qtest/libqos/generic-pcihost.h
    M tests/qtest/libqos/meson.build

  Log Message:
  -----------
  tests/qtest/libqos: Add generic pci host bridge in arm-virt machine

Up to now the virt-machine node contains a virtio-mmio node.
However no driver produces any PCI interface node. Hence, PCI
tests cannot be run with aarch64 binary.

Add a GPEX driver node that produces a pci interface node. This latter
then can be consumed by all the pci tests. One of the first motivation
was to be able to run the virtio-iommu-pci tests.

We still face an issue with pci hotplug tests as hotplug cannot happen
on the pcie root bus and require a generic root port. This will be
addressed later on.

We force cpu=max along with aarch64/virt machine as some PCI tests
require high MMIO regions to be available.

Signed-off-by: Eric Auger <eric.auger@redhat.com>

Message-Id: <20220210145254.157790-6-eric.auger@redhat.com>
Signed-off-by: Eric Auger <eric.auger@redhat.com>


  Commit: 5b2d11c5e916ccff9a034d0350d108bd3a6f45f6
      
https://github.com/qemu/qemu/commit/5b2d11c5e916ccff9a034d0350d108bd3a6f45f6
  Author: Laurent Vivier <lvivier@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-vdpa.c

  Log Message:
  -----------
  hw/virtio: vdpa: Fix leak of host-notifier memory-region

If call virtio_queue_set_host_notifier_mr fails, should free
host-notifier memory-region.

This problem can trigger a coredump with some vDPA drivers (mlx5,
but not with the vdpasim), if we unplug the virtio-net card from
the guest after a stop/start.

The same fix has been done for vhost-user:
  1f89d3b91e3e ("hw/virtio: Fix leak of host-notifier memory-region")

Fixes: d0416d487bd5 ("vhost-vdpa: map virtqueue notification area if possible")
Cc: jasowang@redhat.com
Resolves: https://bugzilla.redhat.com/2027208
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Message-Id: <20220211170259.1388734-1-lvivier@redhat.com>
Cc: qemu-stable@nongnu.org
Acked-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 242080ca95043c6810c95ca72ed6de4328f85863
      
https://github.com/qemu/qemu/commit/242080ca95043c6810c95ca72ed6de4328f85863
  Author: Laurent Vivier <lvivier@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-vdpa.c

  Log Message:
  -----------
  vhost-vdpa: make notifiers _init()/_uninit() symmetric

vhost_vdpa_host_notifiers_init() initializes queue notifiers
for queues "dev->vq_index" to queue "dev->vq_index + dev->nvqs",
whereas vhost_vdpa_host_notifiers_uninit() uninitializes the
same notifiers for queue "0" to queue "dev->nvqs".

This asymmetry seems buggy, fix that by using dev->vq_index
as the base for both.

Fixes: d0416d487bd5 ("vhost-vdpa: map virtqueue notification area if possible")
Cc: jasowang@redhat.com
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Message-Id: <20220211161309.1385839-1-lvivier@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 50957330b356339b243906ff936aa3991a0ddb2f
      
https://github.com/qemu/qemu/commit/50957330b356339b243906ff936aa3991a0ddb2f
  Author: Jason Wang <jasowang@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/i386/intel_iommu.c
    M hw/i386/intel_iommu_internal.h
    M include/hw/i386/intel_iommu.h

  Log Message:
  -----------
  intel_iommu: support snoop control

SC is required for some kernel features like vhost-vDPA. So this patch
implements basic SC feature. The idea is pretty simple, for software
emulated DMA it would be always coherent. In this case we can simple
advertise ECAP_SC bit. For VFIO and vhost, thing will be more much
complicated, so this patch simply fail the IOMMU notifier
registration.

In the future, we may want to have a dedicated notifiers flag or
similar mechanism to demonstrate the coherency so VFIO could advertise
that if it has VFIO_DMA_CC_IOMMU, for vhost kernel backend we don't
need that since it's a software backend.

Signed-off-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20220214060346.72455-1-jasowang@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 69f8206b6261de0368ab9fc6ae1583bcc58561bf
      
https://github.com/qemu/qemu/commit/69f8206b6261de0368ab9fc6ae1583bcc58561bf
  Author: Dov Murik <dovmurik@linux.ibm.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/i386/pc_sysfw_ovmf.c

  Log Message:
  -----------
  hw/i386: Improve bounds checking in OVMF table parsing

When pc_system_parse_ovmf_flash() parses the optional GUIDed table in
the end of the OVMF flash memory area, the table length field is checked
for sizes that are too small, but doesn't error on sizes that are too
big (bigger than the flash content itself).

Add a check for maximal size of the OVMF table, and add an error report
in case the size is invalid.  In such a case, an error like this will be
displayed during launch:

    qemu-system-x86_64: OVMF table has invalid size 4047

and the table parsing is skipped.

Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Message-Id: <20220222071906.2632426-2-dovmurik@linux.ibm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 0e5d0b350e2099a1f8a5e164c3da7ba7a0277e91
      
https://github.com/qemu/qemu/commit/0e5d0b350e2099a1f8a5e164c3da7ba7a0277e91
  Author: Dov Murik <dovmurik@linux.ibm.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/i386/pc_sysfw_ovmf.c

  Log Message:
  -----------
  hw/i386: Replace magic number with field length calculation

Replce the literal magic number 48 with length calculation (32 bytes at
the end of the firmware after the table footer + 16 bytes of the OVMF
table footer GUID).

No functional change intended.

Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Message-Id: <20220222071906.2632426-3-dovmurik@linux.ibm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


  Commit: dd19efdfb3437aa70ad37439138928c392bac9be
      
https://github.com/qemu/qemu/commit/dd19efdfb3437aa70ad37439138928c392bac9be
  Author: Jean-Philippe Brucker <jean-philippe@linaro.org>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/virtio/trace-events
    M hw/virtio/virtio-iommu.c
    M include/hw/virtio/virtio-iommu.h

  Log Message:
  -----------
  virtio-iommu: Default to bypass during boot

Currently the virtio-iommu device must be programmed before it allows
DMA from any PCI device. This can make the VM entirely unusable when a
virtio-iommu driver isn't present, for example in a bootloader that
loads the OS from storage.

Similarly to the other vIOMMU implementations, default to DMA bypassing
the IOMMU during boot. Add a "boot-bypass" property, defaulting to true,
that lets users change this behavior.

Replace the VIRTIO_IOMMU_F_BYPASS feature, which didn't support bypass
before feature negotiation, with VIRTIO_IOMMU_F_BYPASS_CONFIG.

We add the bypass field to the migration stream without introducing
subsections, based on the assumption that this virtio-iommu device isn't
being used in production enough to require cross-version migration at
the moment (all previous version required workarounds since they didn't
support ACPI and boot-bypass).

Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Message-Id: <20220214124356.872985-3-jean-philippe@linaro.org>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 0f2ad8121c45231890a1be2c40794b12fe135b16
      
https://github.com/qemu/qemu/commit/0f2ad8121c45231890a1be2c40794b12fe135b16
  Author: Jean-Philippe Brucker <jean-philippe@linaro.org>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

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

  Log Message:
  -----------
  virtio-iommu: Support bypass domain

The driver can create a bypass domain by passing the
VIRTIO_IOMMU_ATTACH_F_BYPASS flag on the ATTACH request. Bypass domains
perform slightly better than domains with identity mappings since they
skip translation.

Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Message-Id: <20220214124356.872985-4-jean-philippe@linaro.org>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 7e358d258e5e635df226ef530f12d1453f2ae318
      
https://github.com/qemu/qemu/commit/7e358d258e5e635df226ef530f12d1453f2ae318
  Author: Jean-Philippe Brucker <jean-philippe@linaro.org>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M tests/qtest/virtio-iommu-test.c

  Log Message:
  -----------
  tests/qtest/virtio-iommu-test: Check bypass config

The bypass config field should be initialized to 1 by default.

Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Message-Id: <20220214124356.872985-5-jean-philippe@linaro.org>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Thomas Huth <thuth@redhat.com>


  Commit: 3e7c4bb48e6b6d21e2a4d7cff5b8772d5a77d4b8
      
https://github.com/qemu/qemu/commit/3e7c4bb48e6b6d21e2a4d7cff5b8772d5a77d4b8
  Author: Thomas Huth <thuth@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M docs/about/deprecated.rst
    M hw/i386/pc_piix.c

  Log Message:
  -----------
  hw/i386/pc_piix: Mark the machine types from version 1.4 to 1.7 as deprecated

The list of machine types grows larger and larger each release ... and
it is unlikely that many people still use the very old ones for live
migration. QEMU v1.7 has been released more than 8 years ago, so most
people should have updated their machines to a newer version in those
8 years at least once. Thus let's mark the very old 1.x machine types
as deprecated now.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20220117191639.278497-1-thuth@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 7dc610a915e8baf8c8b9761ee4d8d1b188977879
      
https://github.com/qemu/qemu/commit/7dc610a915e8baf8c8b9761ee4d8d1b188977879
  Author: Jonathan Cameron <jonathan.cameron@huawei.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/pci-bridge/pci_expander_bridge.c

  Log Message:
  -----------
  hw/pci-bridge/pxb: Fix missing swizzle

pxb_map_irq_fn() handled the necessary removal of the swizzle
applied to the PXB interrupts by the bus to which it was attached
but neglected to apply the normal swizzle for PCI root ports
on the expander bridge.

Result of this was on ARM virt, the PME interrupts for a second
RP on a PXB instance were miss-routed to #45 rather than #46.

Tested with a selection of different configurations with 1 to 5
RP per PXB instance.  Note on my x86 test setup the PME interrupts
are not triggered so I haven't been able to test this.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Message-Id: <20220118174855.19325-1-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 07178a43d5386e3ffa14c5bb903730a47c9716e1
      
https://github.com/qemu/qemu/commit/07178a43d5386e3ffa14c5bb903730a47c9716e1
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

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

  Log Message:
  -----------
  virtio-net: Unlimit tx queue size if peer is vdpa

The code used to limit the maximum size of tx queue for others backends
than vhost_user since the introduction of configurable tx queue size in
9b02e1618cf2 ("virtio-net: enable configurable tx queue size").

As vhost_user, vhost_vdpa devices should deal with memory region
crosses already, so let's use the full tx size.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20220217175029.2517071-1-eperezma@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 1e610590b9558ade5b3acb750cc588c6859c82fd
      
https://github.com/qemu/qemu/commit/1e610590b9558ade5b3acb750cc588c6859c82fd
  Author: Knut Omang <knut.omang@oracle.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/pci/meson.build
    M hw/pci/pci.c
    M hw/pci/pcie.c
    A hw/pci/pcie_sriov.c
    M hw/pci/trace-events
    M include/hw/pci/pci.h
    M include/hw/pci/pcie.h
    A include/hw/pci/pcie_sriov.h
    M include/qemu/typedefs.h

  Log Message:
  -----------
  pcie: Add support for Single Root I/O Virtualization (SR/IOV)

This patch provides the building blocks for creating an SR/IOV
PCIe Extended Capability header and register/unregister
SR/IOV Virtual Functions.

Signed-off-by: Knut Omang <knuto@ifi.uio.no>
Message-Id: <20220217174504.1051716-2-lukasz.maniak@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: fa6b68ff7ed0e82eb4236c7b782c101492063193
      
https://github.com/qemu/qemu/commit/fa6b68ff7ed0e82eb4236c7b782c101492063193
  Author: Knut Omang <knut.omang@oracle.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    A docs/pcie_sriov.txt

  Log Message:
  -----------
  pcie: Add some SR/IOV API documentation in docs/pcie_sriov.txt

Add a small intro + minimal documentation for how to
implement SR/IOV support for an emulated device.

Signed-off-by: Knut Omang <knuto@ifi.uio.no>
Message-Id: <20220217174504.1051716-3-lukasz.maniak@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 3e7abcc771104d38ad9ffe92c4a8a8e8ca465cf6
      
https://github.com/qemu/qemu/commit/3e7abcc771104d38ad9ffe92c4a8a8e8ca465cf6
  Author: Łukasz Gieryk <lukasz.gieryk@linux.intel.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/pci/pcie_sriov.c
    M include/hw/pci/pcie_sriov.h

  Log Message:
  -----------
  pcie: Add a helper to the SR/IOV API

Convenience function for retrieving the PCIDevice object of the N-th VF.

Signed-off-by: Łukasz Gieryk <lukasz.gieryk@linux.intel.com>
Reviewed-by: Knut Omang <knuto@ifi.uio.no>
Message-Id: <20220217174504.1051716-4-lukasz.maniak@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 23ddbd9c3be9a0f0a5823e7845d76c3ce09cb874
      
https://github.com/qemu/qemu/commit/23ddbd9c3be9a0f0a5823e7845d76c3ce09cb874
  Author: Łukasz Gieryk <lukasz.gieryk@linux.intel.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M include/hw/pci/pci_regs.h

  Log Message:
  -----------
  pcie: Add 1.2 version token for the Power Management Capability

Signed-off-by: Łukasz Gieryk <lukasz.gieryk@linux.intel.com>
Message-Id: <20220217174504.1051716-5-lukasz.maniak@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 5a6cbe1bdad3fe59692af7cbe0bfc9bfc8fd0603
      
https://github.com/qemu/qemu/commit/5a6cbe1bdad3fe59692af7cbe0bfc9bfc8fd0603
  Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/pci-bridge/xio3130_upstream.c

  Log Message:
  -----------
  pci-bridge/xio3130_upstream: Fix error handling

Goto label is incorrect so msi cleanup would not occur if there is
an error in the ssvid initialization.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20220218102303.7061-1-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 02c98b6d2652b9e11175f65fe1924d39c7ec9881
      
https://github.com/qemu/qemu/commit/02c98b6d2652b9e11175f65fe1924d39c7ec9881
  Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/pci-bridge/xio3130_downstream.c

  Log Message:
  -----------
  pci-bridge/xio3130_downstream: Fix error handling

Wrong goto label, so msi cleanup would not occur if there is
an error in the ssvid initialization.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20220218102303.7061-2-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: fe3ddcd9945163ef192ff70b9fb37e98ce9584f4
      
https://github.com/qemu/qemu/commit/fe3ddcd9945163ef192ff70b9fb37e98ce9584f4
  Author: zhenwei pi <pizhenwei@bytedance.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    A include/standard-headers/linux/pvpanic.h
    M scripts/update-linux-headers.sh

  Log Message:
  -----------
  headers: Add pvpanic.h

Since 2020, linux kernel started to export pvpanic.h. Import the
latest version from linux into QEMU.

Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Message-Id: <20220221122717.1371010-1-pizhenwei@bytedance.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>


  Commit: 19b71d7b83b36d60fea64e60d29829b81955d642
      
https://github.com/qemu/qemu/commit/19b71d7b83b36d60fea64e60d29829b81955d642
  Author: zhenwei pi <pizhenwei@bytedance.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/misc/pvpanic-isa.c
    M hw/misc/pvpanic-pci.c
    M hw/misc/pvpanic.c
    M include/hw/misc/pvpanic.h

  Log Message:
  -----------
  hw/misc/pvpanic: Use standard headers instead

QEMU side has already imported pvpanic.h from linux, remove bit
definitions from include/hw/misc/pvpanic.h, and use
include/standard-headers/linux/pvpanic.h instead.
Also minor changes for PVPANIC_CRASHLOADED -> PVPANIC_CRASH_LOADED.

Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Message-Id: <20220221122717.1371010-2-pizhenwei@bytedance.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>


  Commit: f0abd5881599bdb5f251547f6d8a03544569a69b
      
https://github.com/qemu/qemu/commit/f0abd5881599bdb5f251547f6d8a03544569a69b
  Author: Zhenzhong Duan <zhenzhong.duan@intel.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/pci/pci.c

  Log Message:
  -----------
  pci: show id info when pci BDF conflict

During qemu init stage, when there is pci BDF conflicts, qemu print
a warning but not showing which device the BDF is occupied by. E.x:

"PCI: slot 2 function 0 not available for virtio-scsi-pci, in use by 
virtio-scsi-pci"

To facilitate user knowing the offending device and fixing it, showing
the id info in the warning.

Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Message-Id: <20220223094435.64495-1-zhenzhong.duan@intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 68abad85e129969ad489763a48879411d3321284
      
https://github.com/qemu/qemu/commit/68abad85e129969ad489763a48879411d3321284
  Author: Igor Mammedov <imammedo@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/pci-bridge/xio3130_downstream.c
    A include/hw/pci-bridge/xio3130_downstream.h

  Log Message:
  -----------
  pci: expose TYPE_XIO3130_DOWNSTREAM name

Type name will be used in followup patch for cast check
in pcihp code.

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220301151200.3507298-2-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 9289459db7eb4687fb7035aa631b8359ae28482f
      
https://github.com/qemu/qemu/commit/9289459db7eb4687fb7035aa631b8359ae28482f
  Author: Igor Mammedov <imammedo@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/acpi/pcihp.c
    M hw/pci/pcie.c
    M include/hw/pci/pcie.h

  Log Message:
  -----------
  acpi: pcihp: pcie: set power on cap on parent slot

on creation a PCIDevice has power turned on at the end of pci_qdev_realize()
however later on if PCIe slot isn't populated with any children
it's power is turned off. It's fine if native hotplug is used
as plug callback will power slot on among other things.
However when ACPI hotplug is enabled it replaces native PCIe plug
callbacks with ACPI specific ones (acpi_pcihp_device_*plug_cb) and
as result slot stays powered off. It works fine as ACPI hotplug
on guest side takes care of enumerating/initializing hotplugged
device. But when later guest is migrated, call chain introduced by]
commit d5daff7d312 (pcie: implement slot power control for pcie root ports)

   pcie_cap_slot_post_load()
       -> pcie_cap_update_power()
           -> pcie_set_power_device()
               -> pci_set_power()
                   -> pci_update_mappings()

will disable earlier initialized BARs for the hotplugged device
in powered off slot due to commit 23786d13441 (pci: implement power state)
which disables BARs if power is off.

Fix it by setting PCI_EXP_SLTCTL_PCC to PCI_EXP_SLTCTL_PWR_ON
on slot (root port/downstream port) at the time a device
hotplugged into it. As result PCI_EXP_SLTCTL_PWR_ON is migrated
to target and above call chain keeps device plugged into it
powered on.

Fixes: d5daff7d312 ("pcie: implement slot power control for pcie root ports")
Fixes: 23786d13441 ("pci: implement power state")
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2053584
Suggested-by: "Michael S. Tsirkin" <mst@redhat.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220301151200.3507298-3-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: c7fd14d31ba5d40ccce3b6ab548955f3bf0dc4d7
      
https://github.com/qemu/qemu/commit/c7fd14d31ba5d40ccce3b6ab548955f3bf0dc4d7
  Author: Joelle van Dyne <j@getutm.app>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

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

  Log Message:
  -----------
  pc: add option to disable PS/2 mouse/keyboard

On some older software like Windows 7 installer, having both a PS/2
mouse and USB mouse results in only one device working property (which
might be a different device each boot). While the workaround to not use
a USB mouse with such software is valid, it creates an inconsistent
experience if the user wishes to always use a USB mouse.

This introduces a new machine property to inhibit the creation of the
i8042 PS/2 controller.

Signed-off-by: Joelle van Dyne <j@getutm.app>
Message-Id: <20220227210655.45592-1-j@getutm.app>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 2a2e71590ec8d0d7f7089d67c3f3295fea55f72f
      
https://github.com/qemu/qemu/commit/2a2e71590ec8d0d7f7089d67c3f3295fea55f72f
  Author: Stefano Garzarella <sgarzare@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/virtio/vhost-vsock-common.c

  Log Message:
  -----------
  vhost-vsock: detach the virqueue element in case of error

In vhost_vsock_common_send_transport_reset(), if an element popped from
the virtqueue is invalid, we should call virtqueue_detach_element() to
detach it from the virtqueue before freeing its memory.

Fixes: fc0b9b0e1c ("vhost-vsock: add virtio sockets device")
Fixes: CVE-2022-26354
Cc: qemu-stable@nongnu.org
Reported-by: VictorV <vv474172261@gmail.com>
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Message-Id: <20220228095058.27899-1-sgarzare@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: c76e2605599102a62494645ae6bbcb8407aacf3d
      
https://github.com/qemu/qemu/commit/c76e2605599102a62494645ae6bbcb8407aacf3d
  Author: Igor Mammedov <imammedo@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/i386/x86.c
    M include/hw/i386/x86.h

  Log Message:
  -----------
  x86: cleanup unused compat_apic_id_mode

commit
  f862ddbb1a4 (hw/i386: Remove the deprecated pc-1.x machine types)
removed the last user of broken APIC ID compat knob,
but compat_apic_id_mode itself was forgotten.
Clean it up and simplify x86_cpu_apic_id_from_index()

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220228131634.3389805-1-imammedo@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: ac1fac5c53ad5d7263de6bcf997dab433b61ee7c
      
https://github.com/qemu/qemu/commit/ac1fac5c53ad5d7263de6bcf997dab433b61ee7c
  Author: Sergio Lopez <slp@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M include/qemu/event_notifier.h
    M util/event_notifier-posix.c

  Log Message:
  -----------
  event_notifier: add event_notifier_get_wfd()

event_notifier_get_fd(const EventNotifier *e) always returns
EventNotifier's read file descriptor (rfd). This is not a problem when
the EventNotifier is backed by a an eventfd, as a single file
descriptor is used both for reading and triggering events (rfd ==
wfd).

But, when EventNotifier is backed by a pipe pair, we have two file
descriptors, one that can only be used for reads (rfd), and the other
only for writes (wfd).

There's, at least, one known situation in which we need to obtain wfd
instead of rfd, which is when setting up the file that's going to be
sent to the peer in vhost's SET_VRING_CALL.

Add a new event_notifier_get_wfd(const EventNotifier *e) that can be
used to obtain wfd where needed.

Signed-off-by: Sergio Lopez <slp@redhat.com>
Message-Id: <20220303115911.20962-2-slp@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: aff095a4cd366bdf3c845519d1f8f47dd9a677b5
      
https://github.com/qemu/qemu/commit/aff095a4cd366bdf3c845519d1f8f47dd9a677b5
  Author: Sergio Lopez <slp@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M hw/virtio/vhost.c

  Log Message:
  -----------
  vhost: use wfd on functions setting vring call fd

When ioeventfd is emulated using qemu_pipe(), only EventNotifier's wfd
can be used for writing.

Use the recently introduced event_notifier_get_wfd() function to
obtain the fd that our peer must use to signal the vring.

Signed-off-by: Sergio Lopez <slp@redhat.com>
Message-Id: <20220303115911.20962-3-slp@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 598fa38595beb7c1bdea33d76d028f0c55583f8a
      
https://github.com/qemu/qemu/commit/598fa38595beb7c1bdea33d76d028f0c55583f8a
  Author: Sergio Lopez <slp@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M configure
    M meson.build

  Log Message:
  -----------
  configure, meson: allow enabling vhost-user on all POSIX systems

With the possibility of using a pipe pair via qemu_pipe() as a
replacement on operating systems that doesn't support eventfd,
vhost-user can also work on all POSIX systems.

This change allows enabling vhost-user on all non-Windows platforms
and makes libvhost_user (which still depends on eventfd) a linux-only
feature.

Signed-off-by: Sergio Lopez <slp@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20220304100854.14829-4-slp@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>


  Commit: 74bc2c502da74191a34fb61b4c890061368269c8
      
https://github.com/qemu/qemu/commit/74bc2c502da74191a34fb61b4c890061368269c8
  Author: Sergio Lopez <slp@redhat.com>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M docs/interop/vhost-user.rst

  Log Message:
  -----------
  docs: vhost-user: add subsection for non-Linux platforms

Add a section explaining how vhost-user is supported on platforms
other than Linux.

Signed-off-by: Sergio Lopez <slp@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20220304100854.14829-5-slp@redhat.com>
Signed-off-by: Sergio Lopez <slp@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>


  Commit: 0890184864f11402f3958764def19a9c49311994
      
https://github.com/qemu/qemu/commit/0890184864f11402f3958764def19a9c49311994
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2022-03-04 (Fri, 04 Mar 2022)

  Changed paths:
    M MAINTAINERS
    M configure
    M docs/about/deprecated.rst
    M docs/interop/vhost-user.rst
    A docs/pcie_sriov.txt
    A docs/specs/acpi_erst.rst
    M docs/specs/index.rst
    M docs/specs/pci-ids.txt
    M hw/acpi/erst.c
    M hw/acpi/pcihp.c
    M hw/i386/intel_iommu.c
    M hw/i386/intel_iommu_internal.h
    M hw/i386/pc.c
    M hw/i386/pc_piix.c
    M hw/i386/pc_sysfw_ovmf.c
    M hw/i386/x86.c
    M hw/misc/pvpanic-isa.c
    M hw/misc/pvpanic-pci.c
    M hw/misc/pvpanic.c
    M hw/net/virtio-net.c
    M hw/pci-bridge/pci_expander_bridge.c
    M hw/pci-bridge/xio3130_downstream.c
    M hw/pci-bridge/xio3130_upstream.c
    M hw/pci/meson.build
    M hw/pci/pci.c
    M hw/pci/pcie.c
    A hw/pci/pcie_sriov.c
    M hw/pci/trace-events
    M hw/smbios/smbios.c
    M hw/virtio/trace-events
    M hw/virtio/vhost-user-i2c.c
    M hw/virtio/vhost-user.c
    M hw/virtio/vhost-vdpa.c
    M hw/virtio/vhost-vsock-common.c
    M hw/virtio/vhost.c
    M hw/virtio/virtio-bus.c
    M hw/virtio/virtio-iommu.c
    M include/hw/i386/intel_iommu.h
    M include/hw/i386/pc.h
    M include/hw/i386/x86.h
    M include/hw/misc/pvpanic.h
    A include/hw/pci-bridge/xio3130_downstream.h
    M include/hw/pci/pci.h
    M include/hw/pci/pci_regs.h
    M include/hw/pci/pcie.h
    A include/hw/pci/pcie_sriov.h
    M include/hw/virtio/vhost-user-i2c.h
    M include/hw/virtio/vhost-user.h
    M include/hw/virtio/virtio-iommu.h
    M include/qemu/event_notifier.h
    M include/qemu/typedefs.h
    A include/standard-headers/linux/pvpanic.h
    M meson.build
    M qom/object.c
    M scripts/update-linux-headers.sh
    M tests/qtest/e1000e-test.c
    M tests/qtest/libqos/arm-virt-machine.c
    A tests/qtest/libqos/generic-pcihost.c
    A tests/qtest/libqos/generic-pcihost.h
    M tests/qtest/libqos/meson.build
    M tests/qtest/libqos/pci-pc.c
    M tests/qtest/libqos/pci-spapr.c
    M tests/qtest/libqos/pci.c
    M tests/qtest/libqos/pci.h
    M tests/qtest/vhost-user-blk-test.c
    M tests/qtest/virtio-blk-test.c
    M tests/qtest/virtio-iommu-test.c
    M tests/qtest/virtio-net-test.c
    M tests/qtest/virtio-rng-test.c
    M util/event_notifier-posix.c

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

virtio,pc,pci: features, cleanups, fixes

vhost-user enabled on non-linux systems
beginning of nvme sriov support
bigger tx queue for vdpa
virtio iommu bypass
pci tests for arm

Fixes, cleanups all over the place

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

# gpg: Signature made Fri 04 Mar 2022 13:31:14 GMT
# gpg:                using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469
# gpg:                issuer "mst@redhat.com"
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full]
# gpg:                 aka "Michael S. Tsirkin <mst@redhat.com>" [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: (45 commits)
  docs: vhost-user: add subsection for non-Linux platforms
  configure, meson: allow enabling vhost-user on all POSIX systems
  vhost: use wfd on functions setting vring call fd
  event_notifier: add event_notifier_get_wfd()
  x86: cleanup unused compat_apic_id_mode
  vhost-vsock: detach the virqueue element in case of error
  pc: add option to disable PS/2 mouse/keyboard
  acpi: pcihp: pcie: set power on cap on parent slot
  pci: expose TYPE_XIO3130_DOWNSTREAM name
  pci: show id info when pci BDF conflict
  hw/misc/pvpanic: Use standard headers instead
  headers: Add pvpanic.h
  pci-bridge/xio3130_downstream: Fix error handling
  pci-bridge/xio3130_upstream: Fix error handling
  pcie: Add 1.2 version token for the Power Management Capability
  pcie: Add a helper to the SR/IOV API
  pcie: Add some SR/IOV API documentation in docs/pcie_sriov.txt
  pcie: Add support for Single Root I/O Virtualization (SR/IOV)
  virtio-net: Unlimit tx queue size if peer is vdpa
  hw/pci-bridge/pxb: Fix missing swizzle
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


Compare: https://github.com/qemu/qemu/compare/8dba67dce3c2...0890184864f1



reply via email to

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