hw/intc/arm_gicv3: Check for !MEMTX_OK instead of MEMTX_ERROR (CVE-2021-3750)
softmmu/physmem: Simplify flatview_write and address_space_access_valid
softmmu/physmem: Introduce MemTxAttrs::memory field and MEMTX_ACCESS_ERROR
(cherry picked from commit b39643dc6ee4fab61b1d840a1124cb407c7c0af1)
Change Ascend710's quirk regions to bar2 for internal causes.
And support Ascend710 2P format now.
Signed-off-by: Wu Binfeng <wubinfeng@huawei.com>
Signed-off-by: yezengruan <yezengruan@huawei.com>
(cherry picked from commit ce1ce575d621f918d1719f8d2fadbbcc68260ada)
vhost-vsock: detach the virqueue element in case of error (CVE-2022-26354)
virtio-net: fix map leaking on error during receive (CVE-2022-26353)
Signed-off-by: yezengruan <yezengruan@huawei.com>
scsi-bus: fix incorrect call for blk_error_retry_reset_timeout()
Revert "monitor: limit io error qmp event to at most once per 60s"
Signed-off-by: Yan Wang <wangyan122@huawei.com>
Signed-off-by: yezengruan <yezengruan@huawei.com>
(cherry picked from commit 054b20fa4e67f996662bcb8cf12c305bcea83303)
The paramter 'cache' is invalid for host device(/dev/xxx). If
'qemu-img create' operator performed on host device, the host
device not support 'cache' would result 'qemu-img create excute'
failed.
Signed-off-by: Jinhua Cao <caojinhua1@huawei.com>
Description:
For coroutine live patch, we need find all coroutines stack and check them
before patching. There is no structure to manage all coroutines in qemu. So we
add a list which contain all running coroutines to accelerate libcare live
patch.
Signed-off-by: jiang-dawei15 <jiangdawei15@huawei.com>
Signed-off-by: yezengruan <yezengruan@huawei.com>
This option changes the thread local storage (TLS) model. Thread-local storage
is a mechanism by which variables are allocated in a way that causes one instance
of the variable per extant thread.
i.global-dynamic
Generates a generic TLS code. The code can be used everywhere and the code can access
variables defined anywhere else. This setting causes the largest size code to be generated
and uses the most run time to produce.
ii.local-dynamic
Generates an optimized TLS code. To use this setting, the thread-local variables must be
defined in the same object in which they are referenced.
iii.initial-exec
Generates a restrictive, optimized TLS code. To use this setting, the thread-local variables
accessed must be defined in one of the modules available to the program.
iv.local-exec
Generates the most restrictive TLS code. To use this setting, the thread-local variables
must be defined in the executable.
Optimize qemu cflags with '-ftls-model=initial-exec' which means we use initial-exec
mode.
The virtiofsd currently crashes when used with glibc 2.35.
That is due to the rseq system call being added to every thread
creation [1][2].
[1]: https://www.efficios.com/blog/2019/02/08/linux-restartable-sequences/
[2]: https://sourceware.org/pipermail/libc-alpha/2022-February/136040.html
This happens not at daemon start, but when a guest connects
/usr/lib/qemu/virtiofsd -f --socket-path=/tmp/testvfsd -o sandbox=chroot \
-o source=/var/guests/j-virtiofs --socket-group=kvm
virtio_session_mount: Waiting for vhost-user socket connection...
# start ok, now guest will connect
virtio_session_mount: Received vhost-user socket connection
virtio_loop: Entry
fv_queue_set_started: qidx=0 started=1
fv_queue_set_started: qidx=1 started=1
Bad system call (core dumped)
We have to put rseq on the seccomp allowlist to avoid that the daemon
is crashing in this case.
Reported-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-id: 20220209111456.3328420-1-christian.ehrhardt@canonical.com
[Moved rseq to its alphabetically ordered position in the seccomp
allowlist.
--Stefan]
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: qinyu <qinyu16@huawei.com>
Fix commit 391dd8f1("scsi-bus: Refactor the code that retries requests"),
which split scsi_dma_restart_bh(), but the object_unref() belongs to
scsi_dma_restart_bh().
So, we should mv object_unref() from scsi_retry_requests() to
scsi_dma_restart_bh().
Signed-off-by: Yan Wang <wangyan122@huawei.com>
pl011-reset-read-FIFO-when-UARTTIMSC-0-UARTICR-0xfff.patch
qcow2-fix-memory-leak-in-qcow2_read_extensions.patch
scsi-disk-define-props-in-scsi_block_disk-to-avoid-m.patch
pcie-Add-pcie-root-port-fast-plug-unplug-feature.patch
pcie-Compat-with-devices-which-do-not-support-Link-W.patch
Signed-off-by: Yan Wang <wangyan122@huawei.com>
We hack into PCI_EXP_LNKCAP to support device fast plug/unplug
for pcie-root-port. However some devices like ioh3420 does not
suport it, so PCI_EXP_LNKCAP is not set for such devices.
Signed-off-by: Ying Fang <fangying1@huawei.com>
Signed-off-by: Yan Wang <wangyan122@huawei.com>
If a device is plugged in the pcie-root-port when VM kernel is
booting, the kernel may wrongly disable the device.
This bug was brought in by two patches of the linux kernel:
https://patchwork.kernel.org/patch/10575355/https://patchwork.kernel.org/patch/10766219/
VM runtime like kata uses this feature to boot microVM,
so we must fix it up. We hack into the pcie native hotplug
patch so that hotplug/unplug will work under this circumstance.
Signed-off-by: Ying Fang <fangying1@huawei.com>
Signed-off-by: Yan Wang <wangyan122@huawei.com>
scsi_block_realize() use scsi_realize() to init some props, but
these props is not defined in scsi_block_disk_properties, so they will
not be freed.
This patch defines these prop in scsi_block_disk_properties to avoid memleaks.
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Signed-off-by: Yan Wang <wangyan122@huawei.com>
We can enable ACPI when AArch64 Linux is booted with QEMU and UEFI (AAVMF).
When VM is booting and the SBSA driver has not initialized, writting data
that exceds 32 bytes will cause the read FIFO full and proceeding data will
be lost. The searil port appears to be stuck in this abnormal situation.
A hack to reset read FIFO when UARTTIMSC=0 & UARTICR=0xffff appears to
resolve the issue.
The question is fully discussed at
https://www.spinics.net/lists/linux-serial/msg23163.html
Signed-off-by: Haibin Wang <wanghaibin.wang@huawei.com>
Reviewed-by: Shannon Zhao <shannon.zhaosl@gmail.com>
Reviewed-by: Ying Fang <fangying1@huawei.com>
Signed-off-by: Yan Wang <wangyan122@huawei.com>
