Skip to content
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

Open
reticulatedpines opened this issue Dec 8, 2021 · 0 comments
Open

Qemu-eos backtrace.c duplicates code #1

reticulatedpines opened this issue Dec 8, 2021 · 0 comments

Comments

@reticulatedpines
Copy link
Owner

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/

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant