Commit Graph

94561 Commits

Author SHA1 Message Date
Paolo Bonzini
1ea5208feb linux-headers: include missing changes from 5.17
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-15 11:50:50 +01:00
Gareth Webb
50fcc7cbb6 target/i386: Throw a #SS when loading a non-canonical IST
Loading a non-canonical address into rsp when handling an interrupt or
performing a far call should raise a #SS not a #GP.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/870
Signed-off-by: Gareth Webb <gareth.webb@umbralsoftware.co.uk>
Message-Id: <164529651121.25406.15337137068584246397-0@git.sr.ht>
[Move get_pg_mode to seg_helper.c for user-mode emulators. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-15 11:50:15 +01:00
Paolo Bonzini
991ec97625 target/i386: only include bits in pg_mode if they are not ignored
LA57/PKE/PKS is only relevant in 64-bit mode, and NXE is only relevant if
PAE is in use.  Since there is code that checks PG_MODE_LA57 to determine
the canonicality of addresses, make sure that the bit is not set by
mistake in 32-bit mode.  While it would not be a problem because 32-bit
addresses by definition fit in both 48-bit and 57-bit address spaces,
it is nicer if get_pg_mode() actually returns whether a feature is enabled,
and it allows a few simplifications in the page table walker.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-15 11:26:20 +01:00
Longpeng(Mike)
def4c5570c kvm/msi: do explicit commit when adding msi routes
We invoke the kvm_irqchip_commit_routes() for each addition to MSI route
table, which is not efficient if we are adding lots of routes in some cases.

This patch lets callers invoke the kvm_irqchip_commit_routes(), so the
callers can decide how to optimize.

[1] https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg00967.html

Signed-off-by: Longpeng <longpeng2@huawei.com>
Message-Id: <20220222141116.2091-3-longpeng2@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-15 11:26:20 +01:00
Longpeng(Mike)
9568690868 kvm-irqchip: introduce new API to support route change
Paolo suggested adding the new API to support route changes [1]. We should invoke
kvm_irqchip_begin_route_changes() before changing the routes, increasing the
KVMRouteChange.changes if the routes are changed, and commit the changes at last.

[1] https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg02898.html

Signed-off-by: Longpeng <longpeng2@huawei.com>
Message-Id: <20220222141116.2091-2-longpeng2@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-15 11:26:20 +01:00
Paolo Bonzini
a6a7ebc817 update meson-buildoptions.sh
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-15 11:26:20 +01:00
Marc-André Lureau
b770f6ce9e qga/vss: update informative message about MinGW
The headers are now all available in MinGW master branch.
(commit 13390dbbf885f and earlier) aiming for 10.0.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20220222194008.610377-4-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-15 11:26:20 +01:00
Marc-André Lureau
872b69e690 qga/vss-win32: check old VSS SDK headers
The VssCoordinator & VssAdmin interfaces have been moved to vsadmin.h in
the Windows SDK.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20220222194008.610377-3-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-15 11:26:20 +01:00
Marc-André Lureau
32478cb6ed meson: fix generic location of vss headers
This is a left-over, despite requesting the change before the merge.

Fixes: commit 8821a389 ("configure, meson: replace VSS SDK checks and options with --enable-vss-sdk")
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20220222194008.610377-2-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-15 11:26:20 +01:00
Vitaly Kuznetsov
d312378e59 vmxcap: Add 5-level EPT bit
5-level EPT is present in Icelake Server CPUs and is supported by QEMU
('vmx-page-walk-5').

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20220221145316.576138-2-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-15 11:26:20 +01:00
Ivan Shcherbakov
5ad93fd351 whpx: Fixed incorrect CR8/TPR synchronization
This fixes the following error triggered when stopping and resuming a 64-bit
Linux kernel via gdb:

qemu-system-x86_64.exe: WHPX: Failed to set virtual processor context, hr=c0350005

The previous logic for synchronizing the values did not take into account
that the lower 4 bits of the CR8 register, containing the priority level,
mapped to bits 7:4 of the APIC.TPR register (see section 10.8.6.1 of
Volume 3 of Intel 64 and IA-32 Architectures Software Developer's Manual).
The caused WHvSetVirtualProcessorRegisters() to fail with an error,
effectively preventing GDB from changing the guest context.

Signed-off-by: Ivan Shcherbakov <ivan@sysprogs.com>
Message-Id: <010b01d82874$bb4ef160$31ecd420$@sysprogs.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-15 11:26:20 +01:00
Ivan Shcherbakov
e561890841 whpx: Fixed reporting of the CPU context to GDB for 64-bit
Make sure that pausing the VM while in 64-bit mode will set the
HF_CS64_MASK flag in env->hflags (see x86_update_hflags() in
target/i386/cpu.c).

Without it, the code in gdbstub.c would only use the 32-bit register values
when debugging 64-bit targets, making debugging effectively impossible.

Signed-off-by: Ivan Shcherbakov <ivan@sysprogs.com>
Message-Id: <00f701d82874$68b02000$3a106000$@sysprogs.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-15 11:26:20 +01:00
Peter Maydell
a72ada1662 -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
 
 iQEcBAABAgAGBQJiMCsfAAoJEO8Ells5jWIRtk0H/3xPsrgRCFJt62ITjD+0C86n
 eJBzsSkYqZIEMfQZ8Rp1QZTzfHf8T4OsqwA7kemTMvW44s4Z5Z+k1rktrIt0t0w0
 ynAenxLqUGhHpSGfGQ2j1iy/DNRCX2MZfIO/Jo3SOzTpIVf4uGyJ/GR6i0iraXW0
 +tOa/nutgnZFYrASmTBH2JgqQAieWrsW+tjxUK+yEC+eRbh2rrzbH8f91OeXxeH6
 RGxmJPnW8XmEkIDIsiYotcrEYHUDYL+fiI5vf5whiEx2U1Vp/OWsBpzcVruOhgG3
 tXI/d/gzRriH59Ly3rqGk/uAMrIIwzswobKp4kpfLiRdET4yJenhNIaBfHejS+w=
 =kiYq
 -----END PGP SIGNATURE-----

Merge tag 'net-pull-request' of https://github.com/jasowang/qemu into staging

# gpg: Signature made Tue 15 Mar 2022 05:58:55 GMT
# gpg:                using RSA key EF04965B398D6211
# gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <jasowang@redhat.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg:          It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 215D 46F4 8246 689E C77F  3562 EF04 965B 398D 6211

* tag 'net-pull-request' of https://github.com/jasowang/qemu:
  vdpa: Expose VHOST_F_LOG_ALL on SVQ
  vdpa: Never set log_base addr if SVQ is enabled
  vdpa: Adapt vhost_vdpa_get_vring_base to SVQ
  vdpa: Add custom IOTLB translations to SVQ
  vhost: Add VhostIOVATree
  util: add iova_tree_find_iova
  util: Add iova_tree_alloc_map
  vhost: Shadow virtqueue buffers forwarding
  vdpa: adapt vhost_ops callbacks to svq
  virtio: Add vhost_svq_get_vring_addr
  vhost: Add vhost_svq_valid_features to shadow vq
  vhost: Add Shadow VirtQueue call forwarding capabilities
  vhost: Add Shadow VirtQueue kick forwarding capabilities
  vhost: Add VhostShadowVirtqueue
  virtio-net: fix map leaking on error during receive

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-03-15 09:53:13 +00:00
Marc-André Lureau
e1c676a254 ui/console: call gfx_switch() even if the current scanout is GL
egl-headless depends on the backing surface to be set before texture are
set and updated. Display it (update=true) iff the current scanout kind
is SURFACE.

Reported-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2022-03-15 12:55:02 +04:00
Marc-André Lureau
2fa2386e38 ui/dbus: do not send 2d scanout until gfx_update
gfx_switch() is called to set the new_surface, not necessarily to
display it. It should be displayed after gfx_update(). Send the whole
scanout only in this case.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2022-03-15 12:54:59 +04:00
Marc-André Lureau
589089feee ui/dbus: fix texture sharing
The DBus listener naively create, update and destroy textures without
taking into account other listeners. The texture were shared, but
texture update was unnecessarily duplicated.

Teach DisplayGLCtx to do optionally shared texture handling. This is
only implemented for DBus display at this point, however the same
infrastructure could potentially be used for other future combinations.

Reported-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2022-03-15 12:54:55 +04:00
Gerd Hoffmann
9b437cd0f9 MAINTAINERS: take edk2
Cc: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-03-15 09:32:22 +01:00
Gerd Hoffmann
a46eff0a35 edk2/docker: use ubuntu 18.04
Upstream CI uses ubuntu 18.04 too, so pick
that version (instead of something newer).

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-03-15 09:32:22 +01:00
Gerd Hoffmann
392c8ac19b edk2/docker: install python3
python2 is not supported any more,
so go install python3 instead.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-03-15 09:32:22 +01:00
Gerd Hoffmann
0e975424f8 tests/acpi: disallow virt memory hotplug changes
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2022-03-15 09:32:22 +01:00
Gerd Hoffmann
ff883fb39e tests/acpi: update expected data files
The switch to edk2 RELEASE builds changes the memory layout a bit,
resulting in a acpi table change.

See commits ca26041500 ("edk2: switch to release builds") and
3891a5996f ("edk2: update binaries to stable202202")

 DefinitionBlock ("", "SSDT", 1, "BOCHS ", "NVDIMM", 0x00000001)
 {
     Scope (\_SB)
     {
         Device (NVDR)
         {
             Name (_HID, "ACPI0012" /* NVDIMM Root Device */)  // _HID: Hardware ID
             Method (NCAL, 5, Serialized)
             {
                 Local6 = MEMA /* \MEMA */
                 {
                     Return (NCAL (Arg0, Arg1, Arg2, Arg3, 0x02))
                 }
             }

             Device (NV02)
             {
                 Name (_ADR, 0x03)  // _ADR: Address
                 Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                 {
                     Return (NCAL (Arg0, Arg1, Arg2, Arg3, 0x03))
                 }
             }
         }
     }

-    Name (MEMA, 0x43D10000)
+    Name (MEMA, 0x43F50000)
 }

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2022-03-15 09:31:44 +01:00
Gerd Hoffmann
3891a5996f edk2: update binaries to stable202202
The switch to edk2 RELEASE builds changes the memory layout a bit,
resulting in a acpi table change.

 DefinitionBlock ("", "SSDT", 1, "BOCHS ", "NVDIMM", 0x00000001)
 {
     Scope (\_SB)
     {
         Device (NVDR)
         {
             Name (_HID, "ACPI0012" /* NVDIMM Root Device */)  // _HID: Hardware ID
             Method (NCAL, 5, Serialized)
             {
                 Local6 = MEMA /* \MEMA */
                 {
                     Return (NCAL (Arg0, Arg1, Arg2, Arg3, 0x02))
                 }
             }

             Device (NV02)
             {
                 Name (_ADR, 0x03)  // _ADR: Address
                 Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                 {
                     Return (NCAL (Arg0, Arg1, Arg2, Arg3, 0x03))
                 }
             }
         }
     }

-    Name (MEMA, 0x43D10000)
+    Name (MEMA, 0x43F50000)
 }

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2022-03-15 07:18:30 +01:00
Gerd Hoffmann
3ce48e499b edk2: add microvm build
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-03-15 07:18:30 +01:00
Gerd Hoffmann
4911df8a7a edk2: .git can be a file
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-03-15 07:18:30 +01:00
Gerd Hoffmann
ca26041500 edk2: switch to release builds
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
2022-03-15 07:18:29 +01:00
Gerd Hoffmann
e2f3137c73 edk2: update submodule to stable202202
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
2022-03-15 07:18:29 +01:00
Gerd Hoffmann
0f78038e8e tests/acpi: allow virt memory hotplug changes
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2022-03-15 07:18:29 +01:00
Eugenio Pérez
12a195fa34 vdpa: Expose VHOST_F_LOG_ALL on SVQ
SVQ is able to log the dirty bits by itself, so let's use it to not
block migration.

Also, ignore set and clear of VHOST_F_LOG_ALL on set_features if SVQ is
enabled. Even if the device supports it, the reports would be nonsense
because SVQ memory is in the qemu region.

The log region is still allocated. Future changes might skip that, but
this series is already long enough.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Eugenio Pérez
773ebc952e vdpa: Never set log_base addr if SVQ is enabled
Setting the log address would make the device start reporting invalid
dirty memory because the SVQ vrings are located in qemu's memory.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Eugenio Pérez
6d0b222666 vdpa: Adapt vhost_vdpa_get_vring_base to SVQ
This is needed to achieve migration, so the destination can restore its
index.

Setting base as last used idx, so destination will see as available all
the entries that the device did not use, including the in-flight
processing ones.

This is ok for networking, but other kinds of devices might have
problems with these retransmissions.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Eugenio Pérez
34e3c94eda vdpa: Add custom IOTLB translations to SVQ
Use translations added in VhostIOVATree in SVQ.

Only introduce usage here, not allocation and deallocation. As with
previous patches, we use the dead code paths of shadow_vqs_enabled to
avoid commiting too many changes at once. These are impossible to take
at the moment.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Eugenio Pérez
ec6122d882 vhost: Add VhostIOVATree
This tree is able to look for a translated address from an IOVA address.

At first glance it is similar to util/iova-tree. However, SVQ working on
devices with limited IOVA space need more capabilities, like allocating
IOVA chunks or performing reverse translations (qemu addresses to iova).

The allocation capability, as "assign a free IOVA address to this chunk
of memory in qemu's address space" allows shadow virtqueue to create a
new address space that is not restricted by guest's addressable one, so
we can allocate shadow vqs vrings outside of it.

It duplicates the tree so it can search efficiently in both directions,
and it will signal overlap if iova or the translated address is present
in any tree.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Eugenio Pérez
193d17be0b util: add iova_tree_find_iova
This function does the reverse operation of iova_tree_find: To look for
a mapping that match a translated address so we can do the reverse.

This have linear complexity instead of logarithmic, but it supports
overlapping HVA. Future developments could reduce it.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Eugenio Pérez
9376bde894 util: Add iova_tree_alloc_map
This iova tree function allows it to look for a hole in allocated
regions and return a totally new translation for a given translated
address.

It's usage is mainly to allow devices to access qemu address space,
remapping guest's one into a new iova space where qemu can add chunks of
addresses.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Eugenio Pérez
100890f7ca vhost: Shadow virtqueue buffers forwarding
Initial version of shadow virtqueue that actually forward buffers. There
is no iommu support at the moment, and that will be addressed in future
patches of this series. Since all vhost-vdpa devices use forced IOMMU,
this means that SVQ is not usable at this point of the series on any
device.

For simplicity it only supports modern devices, that expects vring
in little endian, with split ring and no event idx or indirect
descriptors. Support for them will not be added in this series.

It reuses the VirtQueue code for the device part. The driver part is
based on Linux's virtio_ring driver, but with stripped functionality
and optimizations so it's easier to review.

However, forwarding buffers have some particular pieces: One of the most
unexpected ones is that a guest's buffer can expand through more than
one descriptor in SVQ. While this is handled gracefully by qemu's
emulated virtio devices, it may cause unexpected SVQ queue full. This
patch also solves it by checking for this condition at both guest's
kicks and device's calls. The code may be more elegant in the future if
SVQ code runs in its own iocontext.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Eugenio Pérez
d96be4c894 vdpa: adapt vhost_ops callbacks to svq
First half of the buffers forwarding part, preparing vhost-vdpa
callbacks to SVQ to offer it. QEMU cannot enable it at this moment, so
this is effectively dead code at the moment, but it helps to reduce
patch size.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Eugenio Pérez
dafb34c992 virtio: Add vhost_svq_get_vring_addr
It reports the shadow virtqueue address from qemu virtual address space.

Since this will be different from the guest's vaddr, but the device can
access it, SVQ takes special care about its alignment & lack of garbage
data. It assumes that IOMMU will work in host_page_size ranges for that.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Eugenio Pérez
4725a4181b vhost: Add vhost_svq_valid_features to shadow vq
This allows SVQ to negotiate features with the guest and the device. For
the device, SVQ is a driver. While this function bypasses all
non-transport features, it needs to disable the features that SVQ does
not support when forwarding buffers. This includes packed vq layout,
indirect descriptors or event idx.

Future changes can add support to offer more features to the guest,
since the use of VirtQueue gives this for free. This is left out at the
moment for simplicity.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Eugenio Pérez
a8ac88585d vhost: Add Shadow VirtQueue call forwarding capabilities
This will make qemu aware of the device used buffers, allowing it to
write the guest memory with its contents if needed.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Eugenio Pérez
dff4426fa6 vhost: Add Shadow VirtQueue kick forwarding capabilities
At this mode no buffer forwarding will be performed in SVQ mode: Qemu
will just forward the guest's kicks to the device.

Host memory notifiers regions are left out for simplicity, and they will
not be addressed in this series.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Eugenio Pérez
10857ec0ad vhost: Add VhostShadowVirtqueue
Vhost shadow virtqueue (SVQ) is an intermediate jump for virtqueue
notifications and buffers, allowing qemu to track them. While qemu is
forwarding the buffers and virtqueue changes, it is able to commit the
memory it's being dirtied, the same way regular qemu's VirtIO devices
do.

This commit only exposes basic SVQ allocation and free. Next patches of
the series add functionality like notifications and buffers forwarding.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Jason Wang
abe300d9d8 virtio-net: fix map leaking on error during receive
Commit bedd7e93d0 ("virtio-net: fix use after unmap/free for sg")
tries to fix the use after free of the sg by caching the virtqueue
elements in an array and unmap them at once after receiving the
packets, But it forgot to unmap the cached elements on error which
will lead to leaking of mapping and other unexpected results.

Fixing this by detaching the cached elements on error. This addresses
CVE-2022-26353.

Reported-by: Victor Tom <vv474172261@gmail.com>
Cc: qemu-stable@nongnu.org
Fixes: CVE-2022-26353
Fixes: bedd7e93d0 ("virtio-net: fix use after unmap/free for sg")
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-03-15 13:57:44 +08:00
Peter Maydell
6f4fe14b46 Fixes for s390x host vectors
Fix for arm ldrd unpredictable case
 -----BEGIN PGP SIGNATURE-----
 
 iQFRBAABCgA7FiEEekgeeIaLTbaoWgXAZN846K9+IV8FAmIvfDwdHHJpY2hhcmQu
 aGVuZGVyc29uQGxpbmFyby5vcmcACgkQZN846K9+IV98eQf/QnWavoj3OOhkVhh6
 R0Egrfp+Se/s31D4eAJMerEcFpoOVe39Y85aCinBM7IOfjOc0MClG7r7C8B/JvbF
 U/iQANBxVyAwTgNjGK9rqAL88pb8As9x7Ph7C6IfXdOuodQNENAlXrc2VowiMdA5
 09lwlIkb65zAsTh7XqSP9DxupQcnjJAfTk9YWiFeq+aaz4od/8qadeUgcb3BB3nD
 aoK82BJPkac3f+cM9neNHV0mEoV1Oi03KnH2WjfjJLJJTYDJx7T/3eo4oMUS+Mrl
 pe4gob3aFInbqTQRNSaq3y86ASA0xRMq2h7W+pDzIBdTzUzIPZDMf2Tsuk61K/X+
 KwSKfw==
 =iJSt
 -----END PGP SIGNATURE-----

Merge tag 'pull-tcg-20220314' of https://gitlab.com/rth7680/qemu into staging

Fixes for s390x host vectors
Fix for arm ldrd unpredictable case

# gpg: Signature made Mon 14 Mar 2022 17:32:44 GMT
# gpg:                using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg:                issuer "richard.henderson@linaro.org"
# gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full]
# Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A  05C0 64DF 38E8 AF7E 215F

* tag 'pull-tcg-20220314' of https://gitlab.com/rth7680/qemu:
  tcg/arm: Don't emit UNPREDICTABLE LDRD with Rm == Rt or Rt+1
  tcg/s390x: Fix tcg_out_dup_vec vs general registers
  tcg/s390x: Fix INDEX_op_bitsel_vec vs VSEL
  tcg/s390x: Fix tcg_out_dupi_vec vs VGM

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-03-14 18:11:36 +00:00
Richard Henderson
76cff100be tcg/arm: Don't emit UNPREDICTABLE LDRD with Rm == Rt or Rt+1
The LDRD (register) instruction is UNPREDICTABLE if the Rm register
is the same as either Rt or Rt+1 (the two registers being loaded to).
We weren't making sure we avoided this, with the result that on some
host CPUs like the Cortex-A7 we would get a SIGILL because the CPU
chooses to UNDEF for this particular UNPREDICTABLE case.

Since we've already checked that datalo is aligned, we can simplify
the test vs the Rm operand by aligning it before comparison.  Check
for the two orderings before falling back to two ldr instructions.

We don't bother to do anything similar for tcg_out_ldrd_rwb(),
because it is only used in tcg_out_tlb_read() with a fixed set of
registers which don't overlap.

There is no equivalent UNPREDICTABLE case for STRD.

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/896
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-03-14 10:31:51 -07:00
Richard Henderson
6e591a8569 tcg/s390x: Fix tcg_out_dup_vec vs general registers
We copied the data from the general register input to the
vector register output, but have not yet replicated it.
We intended to fall through into the vector-vector case,
but failed to redirect the input register.

This is caught by an assertion failure in tcg_out_insn_VRIc,
which diagnosed the incorrect register class.

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-03-14 10:31:51 -07:00
Richard Henderson
6e5f9fb799 tcg/s390x: Fix INDEX_op_bitsel_vec vs VSEL
The operands are output in the wrong order: the tcg selector
argument is first, whereas the s390x selector argument is last.

Tested-by: Thomas Huth <thuth@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/898
Fixes: 9bca986df8 ("tcg/s390x: Implement TCG_TARGET_HAS_bitsel_vec")
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-03-14 10:31:51 -07:00
Richard Henderson
a66669c942 tcg/s390x: Fix tcg_out_dupi_vec vs VGM
The immediate operands to VGM were in the wrong order,
producing an inverse mask.

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-03-14 10:31:51 -07:00
Cédric Le Goater
9c10d86fee ppc/pnv: Remove user-created PHB{3,4,5} devices
On a real system with POWER{8,9,10} processors, PHBs are sub-units of
the processor, they can be deactivated by firmware but not plugged in
or out like a PCI adapter on a slot. Nevertheless, having user-created
PHBs in QEMU seemed to be a good idea for testing purposes :

 1. having a limited set of PHBs speedups boot time.
 2. it is useful to be able to mimic a partially broken topology you
    some time have to deal with during bring-up.

PowerNV is also used for distro install tests and having libvirt
support eases these tasks. libvirt prefers to run the machine with
-nodefaults to be sure not to drag unexpected devices which would need
to be defined in the domain file without being specified on the QEMU
command line. For this reason :

 3. -nodefaults should not include default PHBs

User-created PHB{3,4,5} devices satisfied all these needs but reality
proves to be a bit more complex, internally when modeling such
devices, and externally when dealing with the user interface.

Req 1. and 2. can be simply addressed differently with a machine option:
"phb-mask=<uint>", which QEMU would use to enable/disable PHB device
nodes when creating the device tree.

For Req 3., we need to make sure we are taking the right approach. It
seems that we should expose a new type of user-created PHB device, a
generic virtualized one, that libvirt would use and not one depending
on the processor revision. This needs more thinking.

For now, remove user-created PHB{3,4,5} devices. All the cleanups we
did are not lost and they will be useful for the next steps.

Fixes: 5bc67b052b ("ppc/pnv: Introduce user creatable pnv-phb4 devices")
Fixes: 1f6a88fffc ("ppc/pnv: Introduce support for user created PHB3 devices")
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220314130514.529931-1-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-14 15:57:17 +01:00
Frederic Barrat
8e6f45cc3f ppc/pnv: Always create the PHB5 PEC devices
Always create the PECs (PCI Express Controller) for the system. The
PECs host the PHBs and we try to find the matching PEC when creating a
PHB, so it must exist. It also matches what we do on POWER9

Fixes: 623575e16c ("ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge")
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
[ clg: - Rewored commit log
       - Removed dynamic PHB5 ]
Message-Id: <20220310155101.294568-3-fbarrat@linux.ibm.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-14 15:57:17 +01:00
Frederic Barrat
d3df1f6470 ppc/pnv: Introduce a pnv-phb5 device to match root port
We already have the pnv-phb3 and pnv-phb4 devices for POWER8 and
POWER9 respectively. POWER10 uses version 5 of the PHB. It is very
close to the PHB4 from POWER9, at least in our model and we could
almost keep using the PHB4 model. However the matching root port
pnv-phb5-root-port is specific to POWER10 so to avoid confusion as
well as making it easy to introduce differences later, we create a
pnv-phb5 class, which is mostly an alias for pnv-phb4 for now.

With this patch, the command line for a user-created PHB on powernv10
becomes:
  -machine powernv10 -nodefaults -device pnv-phb5 -device pnv-phb5-root-port

Fixes: 623575e16c ("ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge")
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220310155101.294568-2-fbarrat@linux.ibm.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-14 15:57:17 +01:00