-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Qemu-eos backtrace.c duplicates code #1
Comments
kitor
pushed a commit
to kitor/qemu-eos
that referenced
this issue
Mar 3, 2023
Both qemu and qemu-img use writeback cache mode by default, which is already documented in qemu(1). qemu-nbd uses writethrough cache mode by default, and the default cache mode is not documented. According to the qemu-nbd(8): --cache=CACHE The cache mode to be used with the file. See the documentation of the emulator's -drive cache=... option for allowed values. qemu(1) says: The default mode is cache=writeback. So users have no reason to assume that qemu-nbd is using writethough cache mode. The only hint is the painfully slow writing when using the defaults. Looking in git history, it seems that qemu used writethrough in the past to support broken guests that did not flush data properly, or could not flush due to limitations in qemu. But qemu-nbd clients can use NBD_CMD_FLUSH to flush data, so using writethrough does not help anyone. Change the default cache mode to writback, and document the default and available values properly in the online help and manual. With this change converting image via qemu-nbd is 3.5 times faster. $ qemu-img create dst.img 50g $ qemu-nbd -t -f raw -k /tmp/nbd.sock dst.img Before this change: $ hyperfine -r3 "./qemu-img convert -p -f raw -O raw -T none -W fedora34.img nbd+unix:///?socket=/tmp/nbd.sock" Benchmark reticulatedpines#1: ./qemu-img convert -p -f raw -O raw -T none -W fedora34.img nbd+unix:///?socket=/tmp/nbd.sock Time (mean ± σ): 83.639 s ± 5.970 s [User: 2.733 s, System: 6.112 s] Range (min … max): 76.749 s … 87.245 s 3 runs After this change: $ hyperfine -r3 "./qemu-img convert -p -f raw -O raw -T none -W fedora34.img nbd+unix:///?socket=/tmp/nbd.sock" Benchmark reticulatedpines#1: ./qemu-img convert -p -f raw -O raw -T none -W fedora34.img nbd+unix:///?socket=/tmp/nbd.sock Time (mean ± σ): 23.522 s ± 0.433 s [User: 2.083 s, System: 5.475 s] Range (min … max): 23.234 s … 24.019 s 3 runs Users can avoid the issue by using --cache=writeback[1] but the defaults should give good performance for the common use case. [1] https://bugzilla.redhat.com/1990656 Signed-off-by: Nir Soffer <[email protected]> Message-Id: <[email protected]> Reviewed-by: Eric Blake <[email protected]> CC: [email protected] Signed-off-by: Eric Blake <[email protected]> (cherry picked from commit 0961525) Signed-off-by: Michael Roth <[email protected]>
kitor
pushed a commit
to kitor/qemu-eos
that referenced
this issue
Mar 3, 2023
PCI resource reserve capability should use LE format as all other PCI things. If we don't then seabios won't boot: === PCI new allocation pass reticulatedpines#1 === PCI: check devices PCI: QEMU resource reserve cap: size 10000000000000 type io PCI: secondary bus 1 size 10000000000000 type io PCI: secondary bus 1 size 00200000 type mem PCI: secondary bus 1 size 00200000 type prefmem === PCI new allocation pass reticulatedpines#2 === PCI: out of I/O address space This became more important since we started reserving IO by default, previously no one noticed. Fixes: e2a6290 ("hw/pcie-root-port: Fix hotplug for PCI devices requiring IO") Cc: [email protected] Fixes: 226263f ("hw/pci: add QEMU-specific PCI capability to the Generic PCI Express Root Port") Cc: [email protected] Fixes: 6755e61 ("hw/pci: add PCI resource reserve capability to legacy PCI bridge") Cc: [email protected] Tested-by: Thomas Huth <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> (cherry picked from commit 0e464f7) Signed-off-by: Michael Roth <[email protected]>
kitor
pushed a commit
to kitor/qemu-eos
that referenced
this issue
Mar 3, 2023
Without the previous commit, when running 'make check-qtest-i386' with QEMU configured with '--enable-sanitizers' we get: AddressSanitizer:DEADLYSIGNAL ================================================================= ==287878==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000344 ==287878==The signal is caused by a WRITE memory access. ==287878==Hint: address points to the zero page. #0 0x564b2e5bac27 in blk_inc_in_flight block/block-backend.c:1346:5 reticulatedpines#1 0x564b2e5bb228 in blk_pwritev_part block/block-backend.c:1317:5 reticulatedpines#2 0x564b2e5bcd57 in blk_pwrite block/block-backend.c:1498:11 reticulatedpines#3 0x564b2ca1cdd3 in fdctrl_write_data hw/block/fdc.c:2221:17 reticulatedpines#4 0x564b2ca1b2f7 in fdctrl_write hw/block/fdc.c:829:9 reticulatedpines#5 0x564b2dc49503 in portio_write softmmu/ioport.c:201:9 Add the reproducer for CVE-2021-20196. Suggested-by: Alexander Bulekov <[email protected]> Reviewed-by: Darren Kenny <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected] Signed-off-by: John Snow <[email protected]> (cherry picked from commit cc20926) Signed-off-by: Michael Roth <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Old process copied in src/backtrace.c and backtrace.h. New repo has had these copied in, but now they may get out of sync. A better solution should be found.
Long term, we may want to use a third party library to replace all uses of backtrace.c, either as a submodule or a forked repo we maintain, e.g: http://www.mcternan.me.uk/ArmStackUnwinding/
The text was updated successfully, but these errors were encountered: