vmem->bitmap indexes the memory region of the virtio-mem backend at a
granularity of block_size. To calculate the index of target section offset,
the block_size should be divided instead of the bitmap_size.
Fixes: 2044969f0b ("virtio-mem: Implement RamDiscardManager interface")
Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
Message-Id: <20221216062231.11181-1-chenyi.qiang@intel.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: David Hildenbrand <david@redhat.com>
(cherry picked from commit b11cf32e07)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When vIOMMU is enabled, the vq->used_phys is actually the IOVA not
GPA. So we need to translate it to GPA before the syncing otherwise we
may hit the following crash since IOVA could be out of the scope of
the GPA log size. This could be noted when using virtio-IOMMU with
vhost using 1G memory.
Fixes: c471ad0e9b ("vhost_net: device IOTLB support")
Cc: qemu-stable@nongnu.org
Tested-by: Lei Yang <leiyang@redhat.com>
Reported-by: Yalan Zhang <yalzhang@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Message-Id: <20221216033552.77087-1-jasowang@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 345cc1cbcb)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
This reverts commit 435ceea71d95c959c28041e9c5c3a8377592db72.
On bullseye there's no gcc-11, and gcc-10 compiles everything
just fine.
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
Message-Id: <20220403095234.2210-1-yuval.shaia.ml@gmail.com>
Bug-Debian: https://bugs.debian.org/1014589
Guest driver might execute HW commands when shared buffers are not yet
allocated.
This could happen on purpose (malicious guest) or because of some other
guest/host address mapping error.
We need to protect againts such case.
Fixes: CVE-2022-1050
Reported-by: Raven <wxhusst@gmail.com>
Signed-off-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
Gbp-Pq: Name hw-pvrdma-protect-against-guest-driver-CVE-2022-1050.patch
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
Commit-Id: 36a894aeb6
Bug-Debian: https://bugs.debian.org/1018055
The DMA engine is started by I/O access and then itself accesses the
I/O registers, triggering a reentrancy bug.
The following log can reveal it:
==5637==ERROR: AddressSanitizer: stack-overflow
#0 0x5595435f6078 in tulip_xmit_list_update qemu/hw/net/tulip.c:673
#1 0x5595435f204a in tulip_write qemu/hw/net/tulip.c:805:13
#2 0x559544637f86 in memory_region_write_accessor qemu/softmmu/memory.c:492:5
#3 0x5595446379fa in access_with_adjusted_size qemu/softmmu/memory.c:554:18
#4 0x5595446372fa in memory_region_dispatch_write qemu/softmmu/memory.c
#5 0x55954468b74c in flatview_write_continue qemu/softmmu/physmem.c:2825:23
#6 0x559544683662 in flatview_write qemu/softmmu/physmem.c:2867:12
#7 0x5595446833f3 in address_space_write qemu/softmmu/physmem.c:2963:18
#8 0x5595435fb082 in dma_memory_rw_relaxed qemu/include/sysemu/dma.h:87:12
#9 0x5595435fb082 in dma_memory_rw qemu/include/sysemu/dma.h:130:12
#10 0x5595435fb082 in dma_memory_write qemu/include/sysemu/dma.h:171:12
#11 0x5595435fb082 in stl_le_dma qemu/include/sysemu/dma.h:272:1
#12 0x5595435fb082 in stl_le_pci_dma qemu/include/hw/pci/pci.h:910:1
#13 0x5595435fb082 in tulip_desc_write qemu/hw/net/tulip.c:101:9
#14 0x5595435f7e3d in tulip_xmit_list_update qemu/hw/net/tulip.c:706:9
#15 0x5595435f204a in tulip_write qemu/hw/net/tulip.c:805:13
Fix this bug by restricting the DMA engine to memories regions.
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Gbp-Pq: Name tulip-restrict-DMA-engine-to-memories-CVE-2022-2962.patch
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
Forwarded: no
Last-Update: 2022-01-05
Due to the removal of blobs the packaging will not have the roms
dependency set and would fail at configure stage with:
../../tests/qtest/meson.build:272:2: ERROR: Unknown variable "roms".
Switch it back to the former empty intializer.
Gbp-Pq: Name ignore-roms-dependency-in-qtest.patch
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
To: qemu-devel@nongnu.org
Message-Id: <20210906153103.1661195-1-philmd@redhat.com>
Bug-Debian: https://bugs.debian.org/992726
When building QEMU with DEBUG_ATI defined then running with
'-device ati-vga,romfile="" -d unimp,guest_errors -trace ati\*'
we get:
ati_mm_write 4 0x16c0 DP_CNTL <- 0x1
ati_mm_write 4 0x146c DP_GUI_MASTER_CNTL <- 0x2
ati_mm_write 4 0x16c8 DP_MIX <- 0xff0000
ati_mm_write 4 0x16c4 DP_DATATYPE <- 0x2
ati_mm_write 4 0x224 CRTC_OFFSET <- 0x0
ati_mm_write 4 0x142c DST_PITCH_OFFSET <- 0xfe00000
ati_mm_write 4 0x1420 DST_Y <- 0x3fff
ati_mm_write 4 0x1410 DST_HEIGHT <- 0x3fff
ati_mm_write 4 0x1588 DST_WIDTH_X <- 0x3fff3fff
ati_2d_blt: vram:0x7fff5fa00000 addr:0 ds:0x7fff61273800 stride:2560 bpp:32 rop:0xff
ati_2d_blt: 0 0 0, 0 127 0, (0,0) -> (16383,16383) 16383x16383 > ^
ati_2d_blt: pixman_fill(dst:0x7fff5fa00000, stride:254, bpp:8, x:16383, y:16383, w:16383, h:16383, xor:0xff000000)
Thread 3 "qemu-system-i38" received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0 0x00007ffff7f62ce0 in sse2_fill.lto_priv () at /lib64/libpixman-1.so.0
#1 0x00007ffff7f09278 in pixman_fill () at /lib64/libpixman-1.so.0
#2 0x0000555557b5a9af in ati_2d_blt (s=0x631000028800) at hw/display/ati_2d.c:196
#3 0x0000555557b4b5a2 in ati_mm_write (opaque=0x631000028800, addr=5512, data=1073692671, size=4) at hw/display/ati.c:843
#4 0x0000555558b90ec4 in memory_region_write_accessor (mr=0x631000039cc0, addr=5512, ..., size=4, ...) at softmmu/memory.c:492
Commit 584acf34cb ("ati-vga: Fix reverse bit blts") introduced
the local dst_x and dst_y which adjust the (x, y) coordinates
depending on the direction in the SRCCOPY ROP3 operation, but
forgot to address the same issue for the PATCOPY, BLACKNESS and
WHITENESS operations, which also call pixman_fill().
Fix that now by using the adjusted coordinates in the pixman_fill
call, and update the related debug printf().
Reported-by: Qiang Liu <qiangliu@zju.edu.cn>
Fixes: 584acf34cb ("ati-vga: Fix reverse bit blts")
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Gbp-Pq: Name ati_2d-fix-buffer-overflow-in-ati_2d_blt-CVE-2021-3638.patch
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
From version 2.38, binutils default to ISA spec version 20191213. This
means that the csr read/write (csrr*/csrw*) instructions and fence.i
instruction has separated from the `I` extension, become two standalone
extensions: Zicsr and Zifencei. As the kernel uses those instruction,
this causes the following build failure:
CC lib/sbi/sbi_tlb.o
<<BUILDDIR>>/lib/sbi/sbi_tlb.c: Assembler messages:
<<BUILDDIR>>/lib/sbi/sbi_tlb.c:190: Error: unrecognized opcode `fence.i'
make: *** [Makefile:431: <<BUILDDIR>>/build/lib/sbi/sbi_tlb.o] Error 1
The fix is to specify those extensions explicitly in -march. However as
older binutils version do not support this, we first need to detect
that.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Gbp-Pq: Name opensbi-fix-build-with-binutils-2.38.patch
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
The output of "ld -V" changes based on the environment's locale.
Gbp-Pq: Name slof-ensure-ld-is-called-with-C-locale.patch
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
This version string ends up in the slof.bin, leading to
reproducibility issues.
Gbp-Pq: Name slof-remove-user-and-host-from-release-version.patch
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
Two issues break reproducibility; the time and hostname get embedded
in the resulting seabios binary.
Simply drop the hostname from the embedded version string, as it
shouldn't be needed in Debian package builds.
Use the SOURCE_DATE_EPOCH environment variable to set the build date
rather than the current time:
https://reproducible-builds.org/docs/source-date-epoch/
Gbp-Pq: Name seabios-hppa-use-consistent-date-and-remove-hostname.patch
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
Embedding the build time breaks reproducibility. Instead, use the date
specified by the SOURCE_DATE_EPOCH environment variable:
https://reproducible-builds.org/docs/source-date-epoch/
This patch relies on features of GNU date, and will need further
changes for portability to other systems.
Gbp-Pq: Name openbios-use-source_date_epoch-in-makefile.patch
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
gcc-12.2 produces an apparently wrong warning for this file:
roms/openbios/arch/ppc/qemu/init.c:400:10: error: \
array subscript 0 is outside array bounds of ‘uint32_t[0]’ {aka ‘unsigned int[]’} \
[-Werror=array-bounds]
400 | *dsi = 0x48002002;
| =====^===========
Turn this particular -Werror back into warning. Gcc is apparently wrong here.
index e40385a70b..2e214aa079 100644
Gbp-Pq: Name openbios-array-bounds-gcc12.patch
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
Debian ships different modules in different packages.
By default qemu ignores the fact that it can not load
a module, pretending this module never existed.
Give a useful hint about the package where the module
in question resides.
This is a hack, but it makes qemu a bit more user-friendly.
Gbp-Pq: Name note-missing-module-pkg-name.diff
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
Updated: Wed, 31 Aug 2022 12:30:17 +0300
A hackish way to distinguish the case when qemu-user binary is executed
using in-kernel binfmt-misc subsystem with P flag (preserve argv).
We register binfmt interpreter under name /usr/libexec/qemu-binfmt/qemu-foo-binfmt-P
(which is just a symlink to ../../bin/qemu-foo), and if run like that,
qemu-user binary will "know" it should interpret argv[1] & argv[2]
in a special way.
Gbp-Pq: Name linux-user-binfmt-P.diff
Signed-off-by: Cong Liu <liucong2@kylinos.cn>
pc-bios/meson.build tries to link various firmware files to the build
directory, but we DFSG-removed them so the build fails to find them.
Just disable entering the subdir entirely since we buile all the
necessary firmware in d/rules anyway.
Gbp-Pq: Name skip-meson-pc-bios.diff
Signed-off-by: Cong Liu <liucong2@kylinos.cn>