v1:

Non-standard logical geometries break under QEMU.

A virtual disk which contains an operating system which depends on
logical geometries (consistent values being reported from BIOS INT13
AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
logical geometries - for example 56 SPT (sectors per track).
No matter what QEMU will guess - SeaBIOS, for large enough disks - will
use LBA translation, which will report 63 SPT instead.

In addition we can not enforce SeaBIOS to rely on phyiscal geometries at
all. A virtio-blk-pci virtual disk with 255 phyiscal heads can not
report more than 16 physical heads when moved to an IDE controller, the
ATA spec allows a maximum of 16 heads - this is an artifact of
virtualization.

By supplying the logical geometies directly we are able to support such
"exotic" disks.

We will use fw_cfg to do just that.

v2:

Fix missing parenthesis check in
    "hd-geo-test: Add tests for lchs override"

Sam Eiderman (8):
  block: Refactor macros - fix tabbing
  block: Support providing LCHS from user
  bootdevice: Add interface to gather LCHS
  scsi: Propagate unrealize() callback to scsi-hd
  bootdevice: Gather LCHS from all relevant devices
  bootdevice: Refactor get_boot_devices_list
  bootdevice: FW_CFG interface for LCHS values
  hd-geo-test: Add tests for lchs override

 bootdevice.c             | 158 ++++++++++---
 hw/block/virtio-blk.c    |   6 +
 hw/ide/qdev.c            |   7 +-
 hw/nvram/fw_cfg.c        |  14 +-
 hw/scsi/scsi-bus.c       |  15 ++
 hw/scsi/scsi-disk.c      |  14 ++
 include/hw/block/block.h |  22 +-
 include/hw/scsi/scsi.h   |   1 +
 include/sysemu/sysemu.h  |   4 +
 tests/Makefile.include   |   2 +-
 tests/hd-geo-test.c      | 565 +++++++++++++++++++++++++++++++++++++++++++++++
 11 files changed, 767 insertions(+), 41 deletions(-)

-- 
2.13.3
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

Patchew URL: https://patchew.org/QEMU/20190612115939.23825-1-shmuel.eiderman@oracle.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [SeaBIOS] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface
Type: series
Message-id: 20190612115939.23825-1-shmuel.eiderman@oracle.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

From https://github.com/patchew-project/qemu
 * [new tag]               patchew/20190612115939.23825-1-shmuel.eiderman@oracle.com -> patchew/20190612115939.23825-1-shmuel.eiderman@oracle.com
Switched to a new branch 'test'
bdf6a1bd24 hd-geo-test: Add tests for lchs override
d7b67f4193 bootdevice: FW_CFG interface for LCHS values
11a64fd11f bootdevice: Refactor get_boot_devices_list
dce31cf2c7 bootdevice: Gather LCHS from all relevant devices
aaa025aea3 scsi: Propagate unrealize() callback to scsi-hd
ba777cd8b1 bootdevice: Add interface to gather LCHS
ed9b61ee8d block: Support providing LCHS from user
eb61f6f1d3 block: Refactor macros - fix tabbing

=== OUTPUT BEGIN ===
1/8 Checking commit eb61f6f1d35c (block: Refactor macros - fix tabbing)
ERROR: Macros with complex values should be enclosed in parenthesis
#55: FILE: include/hw/block/block.h:65:
+#define DEFINE_BLOCK_CHS_PROPERTIES(_state, _conf)                      \
+    DEFINE_PROP_UINT32("cyls", _state, _conf.cyls, 0),                  \
+    DEFINE_PROP_UINT32("heads", _state, _conf.heads, 0),                \
     DEFINE_PROP_UINT32("secs", _state, _conf.secs, 0)

total: 1 errors, 0 warnings, 37 lines checked

Patch 1/8 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

2/8 Checking commit ed9b61ee8dbf (block: Support providing LCHS from user)
3/8 Checking commit ba777cd8b1e3 (bootdevice: Add interface to gather LCHS)
4/8 Checking commit aaa025aea333 (scsi: Propagate unrealize() callback to scsi-hd)
5/8 Checking commit dce31cf2c7ac (bootdevice: Gather LCHS from all relevant devices)
6/8 Checking commit 11a64fd11f0f (bootdevice: Refactor get_boot_devices_list)
7/8 Checking commit d7b67f4193ef (bootdevice: FW_CFG interface for LCHS values)
8/8 Checking commit bdf6a1bd24bd (hd-geo-test: Add tests for lchs override)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190612115939.23825-1-shmuel.eiderman@oracle.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com

Patchew URL: https://patchew.org/QEMU/20190612115939.23825-1-shmuel.eiderman@oracle.com/



Hi,

This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===

PASS 5 check-qjson /literals/number/simple
PASS 6 check-qjson /literals/number/large
PASS 7 check-qjson /literals/number/float
==9311==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 8 check-qjson /literals/interpolation/valid
PASS 9 check-qjson /literals/interpolation/unkown
PASS 10 check-qjson /literals/interpolation/string
---
PASS 32 test-opts-visitor /visitor/opts/range/beyond
PASS 33 test-opts-visitor /visitor/opts/dict/unvisited
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-coroutine -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-coroutine" 
==9369==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9369==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffc405a1000; bottom 0x7efed01f8000; size: 0x00fd703a9000 (1088509612032)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 1 test-coroutine /basic/no-dangling-access
---
PASS 11 test-aio /aio/event/wait
PASS 12 test-aio /aio/event/flush
PASS 13 test-aio /aio/event/wait/no-flush-cb
==9384==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 14 test-aio /aio/timer/schedule
PASS 15 test-aio /aio/coroutine/queue-chaining
PASS 16 test-aio /aio-gsource/flush
---
PASS 13 fdc-test /x86_64/fdc/fuzz-registers
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img tests/ide-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="ide-test" 
PASS 28 test-aio /aio-gsource/timer/schedule
==9393==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-aio-multithread -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-aio-multithread" 
==9400==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-aio-multithread /aio/multi/lifecycle
PASS 1 ide-test /x86_64/ide/identify
==9414==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 2 test-aio-multithread /aio/multi/schedule
PASS 2 ide-test /x86_64/ide/flush
==9425==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 3 test-aio-multithread /aio/multi/mutex/contended
PASS 3 ide-test /x86_64/ide/bmdma/simple_rw
==9436==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 4 ide-test /x86_64/ide/bmdma/trim
==9442==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 5 ide-test /x86_64/ide/bmdma/short_prdt
==9448==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 4 test-aio-multithread /aio/multi/mutex/handoff
PASS 6 ide-test /x86_64/ide/bmdma/one_sector_short_prdt
==9459==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 5 test-aio-multithread /aio/multi/mutex/mcs
PASS 7 ide-test /x86_64/ide/bmdma/long_prdt
==9470==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9470==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffef4f62000; bottom 0x7fda7dbfe000; size: 0x002477364000 (156618866688)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 6 test-aio-multithread /aio/multi/mutex/pthread
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-throttle -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-throttle" 
PASS 8 ide-test /x86_64/ide/bmdma/no_busmaster
==9478==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-throttle /throttle/leak_bucket
PASS 2 test-throttle /throttle/compute_wait
PASS 3 test-throttle /throttle/init
---
PASS 14 test-throttle /throttle/config/max
PASS 15 test-throttle /throttle/config/iops_size
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-thread-pool -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-thread-pool" 
==9484==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-thread-pool /thread-pool/submit
PASS 2 test-thread-pool /thread-pool/submit-aio
PASS 3 test-thread-pool /thread-pool/submit-co
PASS 4 test-thread-pool /thread-pool/submit-many
PASS 9 ide-test /x86_64/ide/flush/nodev
==9555==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 10 ide-test /x86_64/ide/flush/empty_drive
PASS 5 test-thread-pool /thread-pool/cancel
==9560==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 11 ide-test /x86_64/ide/flush/retry_pci
==9566==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 12 ide-test /x86_64/ide/flush/retry_isa
PASS 6 test-thread-pool /thread-pool/cancel-async
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-hbitmap -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-hbitmap" 
---
PASS 2 test-hbitmap /hbitmap/size/0
PASS 3 test-hbitmap /hbitmap/size/unaligned
PASS 4 test-hbitmap /hbitmap/iter/empty
==9573==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 13 ide-test /x86_64/ide/cdrom/pio
PASS 5 test-hbitmap /hbitmap/iter/partial
PASS 6 test-hbitmap /hbitmap/iter/granularity
---
PASS 10 test-hbitmap /hbitmap/set/all
PASS 11 test-hbitmap /hbitmap/set/one
PASS 12 test-hbitmap /hbitmap/set/two-elem
==9584==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 13 test-hbitmap /hbitmap/set/general
PASS 14 test-hbitmap /hbitmap/set/twice
PASS 15 test-hbitmap /hbitmap/set/overlap
---
PASS 29 test-hbitmap /hbitmap/truncate/shrink/large
PASS 30 test-hbitmap /hbitmap/meta/zero
PASS 14 ide-test /x86_64/ide/cdrom/pio_large
==9590==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 15 ide-test /x86_64/ide/cdrom/dma
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img tests/ahci-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="ahci-test" 
==9604==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 ahci-test /x86_64/ahci/sanity
==9610==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 2 ahci-test /x86_64/ahci/pci_spec
==9616==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 3 ahci-test /x86_64/ahci/pci_enable
PASS 31 test-hbitmap /hbitmap/meta/one
PASS 32 test-hbitmap /hbitmap/meta/byte
PASS 33 test-hbitmap /hbitmap/meta/word
==9622==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 34 test-hbitmap /hbitmap/meta/sector
PASS 35 test-hbitmap /hbitmap/serialize/align
PASS 4 ahci-test /x86_64/ahci/hba_spec
==9628==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 5 ahci-test /x86_64/ahci/hba_enable
==9634==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 36 test-hbitmap /hbitmap/serialize/basic
PASS 37 test-hbitmap /hbitmap/serialize/part
PASS 38 test-hbitmap /hbitmap/serialize/zeroes
---
PASS 42 test-hbitmap /hbitmap/next_dirty_area/next_dirty_area_1
PASS 43 test-hbitmap /hbitmap/next_dirty_area/next_dirty_area_4
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-bdrv-drain -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-bdrv-drain" 
==9641==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-bdrv-drain /bdrv-drain/nested
PASS 2 test-bdrv-drain /bdrv-drain/multiparent
PASS 3 test-bdrv-drain /bdrv-drain/set_aio_context
---
PASS 38 test-bdrv-drain /bdrv-drain/detach/driver_cb
PASS 39 test-bdrv-drain /bdrv-drain/attach/drain
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-bdrv-graph-mod -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-bdrv-graph-mod" 
==9663==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9683==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-bdrv-graph-mod /bdrv-graph-mod/update-perm-tree
PASS 2 test-bdrv-graph-mod /bdrv-graph-mod/should-update-child
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-blockjob -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-blockjob" 
==9693==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 7 ahci-test /x86_64/ahci/max
PASS 1 test-blockjob /blockjob/ids
PASS 2 test-blockjob /blockjob/cancel/created
---
PASS 7 test-blockjob /blockjob/cancel/pending
PASS 8 test-blockjob /blockjob/cancel/concluded
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-blockjob-txn -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-blockjob-txn" 
==9699==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-blockjob-txn /single/success
PASS 2 test-blockjob-txn /single/failure
PASS 3 test-blockjob-txn /single/cancel
---
PASS 6 test-blockjob-txn /pair/cancel
PASS 7 test-blockjob-txn /pair/fail-cancel-race
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-block-backend -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-block-backend" 
==9697==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9704==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-block-backend /block-backend/drain_aio_error
PASS 2 test-block-backend /block-backend/drain_all_aio_error
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-block-iothread -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-block-iothread" 
==9713==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-block-iothread /sync-op/pread
PASS 2 test-block-iothread /sync-op/pwrite
PASS 3 test-block-iothread /sync-op/load_vmstate
---
PASS 15 test-block-iothread /propagate/diamond
PASS 16 test-block-iothread /propagate/mirror
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-image-locking -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-image-locking" 
==9734==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-image-locking /image-locking/basic
PASS 2 test-image-locking /image-locking/set-perm-abort
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-x86-cpuid -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-x86-cpuid" 
PASS 8 ahci-test /x86_64/ahci/reset
PASS 1 test-x86-cpuid /cpuid/topology/basic
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-xbzrle -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-xbzrle" 
==9740==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-xbzrle /xbzrle/uleb
PASS 2 test-xbzrle /xbzrle/encode_decode_zero
PASS 3 test-xbzrle /xbzrle/encode_decode_unchanged
PASS 4 test-xbzrle /xbzrle/encode_decode_1_byte
PASS 5 test-xbzrle /xbzrle/encode_decode_overflow
==9740==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffd68cf9000; bottom 0x7f34dd1fe000; size: 0x00c88bafb000 (861337006080)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 6 test-xbzrle /xbzrle/encode_decode
---
PASS 16 test-vmstate /vmstate/qtailq/save/saveq
PASS 17 test-vmstate /vmstate/qtailq/load/loadq
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-cutils -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-cutils" 
==9753==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-cutils /cutils/parse_uint/null
PASS 2 test-cutils /cutils/parse_uint/empty
PASS 3 test-cutils /cutils/parse_uint/whitespace
---
PASS 133 test-cutils /cutils/strtosz/erange
PASS 134 test-cutils /cutils/strtosz/metric
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-shift128 -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-shift128" 
==9753==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffed77e0000; bottom 0x7f31747fe000; size: 0x00cd62fe2000 (882129117184)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 1 test-shift128 /host-utils/test_lshift
---
PASS 9 test-int128 /int128/int128_gt
PASS 10 test-int128 /int128/int128_rshift
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/rcutorture -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="rcutorture" 
==9776==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9776==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffdd10bd000; bottom 0x7fe7f7bfe000; size: 0x0015d94bf000 (93839945728)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 11 ahci-test /x86_64/ahci/io/pio/lba28/simple/high
PASS 1 rcutorture /rcu/torture/1reader
==9797==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9797==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffef86ef000; bottom 0x7f088d7fe000; size: 0x00f66aef1000 (1058356006912)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 2 rcutorture /rcu/torture/10readers
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-rcu-list -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-rcu-list" 
PASS 12 ahci-test /x86_64/ahci/io/pio/lba28/double/zero
==9826==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9826==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7fffa3254000; bottom 0x7f413d1fe000; size: 0x00be66056000 (817755414528)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 1 test-rcu-list /rcu/qlist/single-threaded
PASS 13 ahci-test /x86_64/ahci/io/pio/lba28/double/low
==9838==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9838==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffd89523000; bottom 0x7f0d33bfe000; size: 0x00f055925000 (1032227803136)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 2 test-rcu-list /rcu/qlist/short-few
PASS 14 ahci-test /x86_64/ahci/io/pio/lba28/double/high
==9865==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9865==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffd43cd9000; bottom 0x7f574c9fe000; size: 0x00a5f72db000 (712816570368)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 15 ahci-test /x86_64/ahci/io/pio/lba28/long/zero
PASS 3 test-rcu-list /rcu/qlist/long-many
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-rcu-simpleq -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-rcu-simpleq" 
==9871==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9871==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7fff80cae000; bottom 0x7fbc349fe000; size: 0x00434c2b0000 (289040695296)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 1 test-rcu-simpleq /rcu/qsimpleq/single-threaded
PASS 16 ahci-test /x86_64/ahci/io/pio/lba28/long/low
==9890==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9890==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffeff502000; bottom 0x7fc155ffe000; size: 0x003da9504000 (264833613824)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 2 test-rcu-simpleq /rcu/qsimpleq/short-few
PASS 17 ahci-test /x86_64/ahci/io/pio/lba28/long/high
==9917==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 18 ahci-test /x86_64/ahci/io/pio/lba28/short/zero
==9923==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 3 test-rcu-simpleq /rcu/qsimpleq/long-many
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-rcu-tailq -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-rcu-tailq" 
PASS 19 ahci-test /x86_64/ahci/io/pio/lba28/short/low
==9936==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-rcu-tailq /rcu/qtailq/single-threaded
PASS 20 ahci-test /x86_64/ahci/io/pio/lba28/short/high
PASS 2 test-rcu-tailq /rcu/qtailq/short-few
==9948==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9948==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7fff42ae7000; bottom 0x7f2a2ddfe000; size: 0x00d514ce9000 (915177115648)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 21 ahci-test /x86_64/ahci/io/pio/lba48/simple/zero
==9975==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9975==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffef2cc8000; bottom 0x7fa8795fe000; size: 0x0056796ca000 (371404349440)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 22 ahci-test /x86_64/ahci/io/pio/lba48/simple/low
PASS 3 test-rcu-tailq /rcu/qtailq/long-many
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-qdist -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-qdist" 
==9981==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-qdist /qdist/none
PASS 2 test-qdist /qdist/pr
PASS 3 test-qdist /qdist/single/empty
---
PASS 6 test-qdist /qdist/binning/precision
PASS 7 test-qdist /qdist/binning/expand
PASS 8 test-qdist /qdist/binning/shrink
==9981==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7fffaafbb000; bottom 0x7fbbfc7fe000; size: 0x0043ae7bd000 (290690158592)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-qht -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-qht" 
PASS 23 ahci-test /x86_64/ahci/io/pio/lba48/simple/high
==9996==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==9996==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffe9bfa9000; bottom 0x7f1ef2dfe000; size: 0x00dfa91ab000 (960614805504)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 24 ahci-test /x86_64/ahci/io/pio/lba48/double/zero
==10002==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==10002==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffc674ec000; bottom 0x7faa78dfe000; size: 0x0051ee6ee000 (351892594688)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 25 ahci-test /x86_64/ahci/io/pio/lba48/double/low
==10008==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==10008==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffc8d007000; bottom 0x7f08a37fe000; size: 0x00f3e9809000 (1047594569728)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 26 ahci-test /x86_64/ahci/io/pio/lba48/double/high
==10014==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==10014==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7fff9be2b000; bottom 0x7fdf973fe000; size: 0x002004a2d000 (137516732416)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 27 ahci-test /x86_64/ahci/io/pio/lba48/long/zero
==10020==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==10020==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffd95971000; bottom 0x7fec041fe000; size: 0x001191773000 (75454951424)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 28 ahci-test /x86_64/ahci/io/pio/lba48/long/low
==10026==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==10026==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffef2a1d000; bottom 0x7fc726f24000; size: 0x0037cbaf9000 (239640481792)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 29 ahci-test /x86_64/ahci/io/pio/lba48/long/high
==10032==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 30 ahci-test /x86_64/ahci/io/pio/lba48/short/zero
==10038==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 31 ahci-test /x86_64/ahci/io/pio/lba48/short/low
==10044==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 32 ahci-test /x86_64/ahci/io/pio/lba48/short/high
==10050==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 33 ahci-test /x86_64/ahci/io/dma/lba28/fragmented
==10056==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 34 ahci-test /x86_64/ahci/io/dma/lba28/retry
PASS 1 test-qht /qht/mode/default
==10062==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 2 test-qht /qht/mode/resize
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-qht-par -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-qht-par" 
PASS 35 ahci-test /x86_64/ahci/io/dma/lba28/simple/zero
==10078==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-qht-par /qht/parallel/2threads-0%updates-1s
PASS 36 ahci-test /x86_64/ahci/io/dma/lba28/simple/low
==10088==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 2 test-qht-par /qht/parallel/2threads-20%updates-1s
PASS 37 ahci-test /x86_64/ahci/io/dma/lba28/simple/high
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-bitops -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-bitops" 
---
PASS 5 test-bitops /bitops/half_unshuffle32
PASS 6 test-bitops /bitops/half_unshuffle64
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-bitcnt -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-bitcnt" 
==10099==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-bitcnt /bitcnt/ctpop8
PASS 2 test-bitcnt /bitcnt/ctpop16
PASS 3 test-bitcnt /bitcnt/ctpop32
---
PASS 18 test-qemu-opts /qemu-opts/to_qdict/filtered
PASS 19 test-qemu-opts /qemu-opts/to_qdict/duplicates
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-keyval -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-keyval" 
==10128==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-keyval /keyval/keyval_parse
PASS 2 test-keyval /keyval/keyval_parse/list
PASS 3 test-keyval /keyval/visit/bool
---
PASS 3 test-crypto-hmac /crypto/hmac/prealloc
PASS 4 test-crypto-hmac /crypto/hmac/digest
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-crypto-cipher -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-crypto-cipher" 
==10156==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-crypto-cipher /crypto/cipher/aes-ecb-128
PASS 2 test-crypto-cipher /crypto/cipher/aes-ecb-192
PASS 3 test-crypto-cipher /crypto/cipher/aes-ecb-256
---
PASS 16 test-crypto-secret /crypto/secret/crypt/badiv
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-crypto-tlscredsx509 -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-crypto-tlscredsx509" 
PASS 40 ahci-test /x86_64/ahci/io/dma/lba28/double/high
==10181==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/perfectserver
PASS 2 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/perfectclient
PASS 3 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodca1
PASS 41 ahci-test /x86_64/ahci/io/dma/lba28/long/zero
PASS 4 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodca2
==10187==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 5 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodca3
PASS 6 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/badca1
PASS 7 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/badca2
PASS 8 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/badca3
PASS 42 ahci-test /x86_64/ahci/io/dma/lba28/long/low
==10193==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 9 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver1
PASS 10 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver2
PASS 11 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver3
PASS 43 ahci-test /x86_64/ahci/io/dma/lba28/long/high
PASS 12 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver4
PASS 13 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver5
==10199==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 14 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver6
PASS 44 ahci-test /x86_64/ahci/io/dma/lba28/short/zero
PASS 15 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/goodserver7
---
PASS 37 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/missingca
PASS 38 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/missingserver
PASS 39 test-crypto-tlscredsx509 /qcrypto/tlscredsx509/missingclient
==10205==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-crypto-tlssession -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-crypto-tlssession" 
PASS 45 ahci-test /x86_64/ahci/io/dma/lba28/short/low
PASS 1 test-crypto-tlssession /qcrypto/tlssession/psk
==10216==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 2 test-crypto-tlssession /qcrypto/tlssession/basicca
PASS 46 ahci-test /x86_64/ahci/io/dma/lba28/short/high
PASS 3 test-crypto-tlssession /qcrypto/tlssession/differentca
==10222==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 4 test-crypto-tlssession /qcrypto/tlssession/altname1
PASS 47 ahci-test /x86_64/ahci/io/dma/lba48/simple/zero
==10228==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 48 ahci-test /x86_64/ahci/io/dma/lba48/simple/low
PASS 5 test-crypto-tlssession /qcrypto/tlssession/altname2
PASS 6 test-crypto-tlssession /qcrypto/tlssession/altname3
PASS 7 test-crypto-tlssession /qcrypto/tlssession/altname4
==10234==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 8 test-crypto-tlssession /qcrypto/tlssession/altname5
PASS 49 ahci-test /x86_64/ahci/io/dma/lba48/simple/high
PASS 9 test-crypto-tlssession /qcrypto/tlssession/altname6
==10240==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 10 test-crypto-tlssession /qcrypto/tlssession/wildcard1
PASS 11 test-crypto-tlssession /qcrypto/tlssession/wildcard2
PASS 50 ahci-test /x86_64/ahci/io/dma/lba48/double/zero
==10246==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 51 ahci-test /x86_64/ahci/io/dma/lba48/double/low
PASS 12 test-crypto-tlssession /qcrypto/tlssession/wildcard3
==10252==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 13 test-crypto-tlssession /qcrypto/tlssession/wildcard4
PASS 52 ahci-test /x86_64/ahci/io/dma/lba48/double/high
PASS 14 test-crypto-tlssession /qcrypto/tlssession/wildcard5
==10258==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 15 test-crypto-tlssession /qcrypto/tlssession/wildcard6
PASS 16 test-crypto-tlssession /qcrypto/tlssession/cachain
PASS 53 ahci-test /x86_64/ahci/io/dma/lba48/long/zero
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-qga -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-qga" 
==10265==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-qga /qga/sync-delimited
PASS 2 test-qga /qga/sync
PASS 3 test-qga /qga/ping
---
PASS 15 test-qga /qga/invalid-cmd
PASS 16 test-qga /qga/invalid-args
PASS 17 test-qga /qga/fsfreeze-status
==10276==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 18 test-qga /qga/blacklist
PASS 55 ahci-test /x86_64/ahci/io/dma/lba48/long/high
PASS 19 test-qga /qga/config
PASS 20 test-qga /qga/guest-exec
PASS 21 test-qga /qga/guest-exec-invalid
==10286==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 22 test-qga /qga/guest-get-osinfo
PASS 23 test-qga /qga/guest-get-host-name
PASS 24 test-qga /qga/guest-get-timezone
---
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-timed-average -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-timed-average" 
PASS 1 test-timed-average /timed-average/average
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-util-filemonitor -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-util-filemonitor" 
==10298==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-util-filemonitor /util/filemonitor
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-util-sockets -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-util-sockets" 
PASS 1 test-util-sockets /util/socket/is-socket/bad
---
PASS 5 test-authz-list /auth/list/explicit/deny
PASS 6 test-authz-list /auth/list/explicit/allow
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-authz-listfile -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-authz-listfile" 
==10330==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-authz-listfile /auth/list/complex
PASS 2 test-authz-listfile /auth/list/default/deny
PASS 3 test-authz-listfile /auth/list/default/allow
---
PASS 4 test-io-channel-file /io/channel/pipe/sync
PASS 5 test-io-channel-file /io/channel/pipe/async
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-io-channel-tls -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-io-channel-tls" 
==10390==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 59 ahci-test /x86_64/ahci/io/ncq/simple
==10408==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-io-channel-tls /qio/channel/tls/basic
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-io-channel-command -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-io-channel-command" 
PASS 60 ahci-test /x86_64/ahci/io/ncq/retry
---
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-io-channel-buffer -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-io-channel-buffer" 
PASS 1 test-io-channel-buffer /io/channel/buf
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-base64 -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-base64" 
==10424==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-base64 /util/base64/good
PASS 2 test-base64 /util/base64/embedded-nul
PASS 3 test-base64 /util/base64/not-nul-terminated
---
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-crypto-block -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-crypto-block" 
PASS 1 test-crypto-block /crypto/block/qcow
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-logging -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-logging" 
==10457==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 1 test-logging /logging/parse_range
PASS 2 test-logging /logging/parse_path
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-replication -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-replication" 
==10474==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 62 ahci-test /x86_64/ahci/flush/retry
PASS 1 test-replication /replication/primary/read
PASS 2 test-replication /replication/primary/write
==10479==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==10484==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 3 test-replication /replication/primary/start
PASS 4 test-replication /replication/primary/stop
PASS 5 test-replication /replication/primary/do_checkpoint
---
PASS 7 test-replication /replication/secondary/read
PASS 63 ahci-test /x86_64/ahci/flush/migrate
PASS 8 test-replication /replication/secondary/write
==10494==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==10499==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==10474==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffeac159000; bottom 0x7f1416efc000; size: 0x00ea9525d000 (1007524630528)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 64 ahci-test /x86_64/ahci/migrate/sanity
PASS 9 test-replication /replication/secondary/start
==10527==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==10532==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 10 test-replication /replication/secondary/stop
PASS 65 ahci-test /x86_64/ahci/migrate/dma/simple
==10541==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==10546==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 11 test-replication /replication/secondary/do_checkpoint
PASS 12 test-replication /replication/secondary/get_error_all
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  tests/test-bufferiszero -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="test-bufferiszero" 
PASS 66 ahci-test /x86_64/ahci/migrate/dma/halted
==10559==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==10564==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 67 ahci-test /x86_64/ahci/migrate/ncq/simple
==10573==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==10578==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 68 ahci-test /x86_64/ahci/migrate/ncq/halted
==10587==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 69 ahci-test /x86_64/ahci/cdrom/eject
==10592==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 70 ahci-test /x86_64/ahci/cdrom/dma/single
==10599==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 71 ahci-test /x86_64/ahci/cdrom/dma/multi
==10605==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 72 ahci-test /x86_64/ahci/cdrom/pio/single
==10611==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
==10611==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 0x7ffe0b989000; bottom 0x7f7bcedfe000; size: 0x00823cb8b000 (559364485120)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 73 ahci-test /x86_64/ahci/cdrom/pio/multi
==10617==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 74 ahci-test /x86_64/ahci/cdrom/pio/bcl
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img tests/hd-geo-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="hd-geo-test" 
PASS 1 hd-geo-test /x86_64/hd-geo/ide/none
==10631==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 2 hd-geo-test /x86_64/hd-geo/ide/drive/cd_0
==10637==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 3 hd-geo-test /x86_64/hd-geo/ide/drive/mbr/blank
==10643==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 4 hd-geo-test /x86_64/hd-geo/ide/drive/mbr/lba
==10649==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 5 hd-geo-test /x86_64/hd-geo/ide/drive/mbr/chs
==10655==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 6 hd-geo-test /x86_64/hd-geo/ide/device/mbr/blank
==10661==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 7 hd-geo-test /x86_64/hd-geo/ide/device/mbr/lba
==10667==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 8 hd-geo-test /x86_64/hd-geo/ide/device/mbr/chs
==10673==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 9 hd-geo-test /x86_64/hd-geo/ide/device/user/chs
==10678==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
PASS 10 hd-geo-test /x86_64/hd-geo/ide/device/user/chst
sh: qemu-img: command not found
**
ERROR:/tmp/qemu-test/src/tests/hd-geo-test.c:477:create_qcow2_with_mbr: assertion failed: (ret == 0)
ERROR - Bail out! ERROR:/tmp/qemu-test/src/tests/hd-geo-test.c:477:create_qcow2_with_mbr: assertion failed: (ret == 0)
make: *** [/tmp/qemu-test/src/tests/Makefile.include:888: check-qtest-x86_64] Error 1
make: *** Waiting for unfinished jobs....
PASS 1 test-bufferiszero /cutils/bufferiszero


The full log is available at
http://patchew.org/logs/20190612115939.23825-1-shmuel.eiderman@oracle.com/testing.asan/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com

On Wed, Jun 12, 2019 at 02:59:31PM +0300, Sam Eiderman wrote:
> v1:
> 
> Non-standard logical geometries break under QEMU.
> 
> A virtual disk which contains an operating system which depends on
> logical geometries (consistent values being reported from BIOS INT13
> AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
> logical geometries - for example 56 SPT (sectors per track).
> No matter what QEMU will guess - SeaBIOS, for large enough disks - will
> use LBA translation, which will report 63 SPT instead.

--verbose please.

As far I know seabios switches to LBA mode when the disk is simply too
big for LCHS addressing.  So I fail to see which problem is solved by
this.  If your guest needs LCHS, why do you assign a disk which can't
be fully accessed using LCHS addressing?

> In addition we can not enforce SeaBIOS to rely on phyiscal geometries at
> all. A virtio-blk-pci virtual disk with 255 phyiscal heads can not
> report more than 16 physical heads when moved to an IDE controller, the
> ATA spec allows a maximum of 16 heads - this is an artifact of
> virtualization.

Well, not really.  Moving disks from one controller to another when the
OS depends on LHCS addressing never is a good idea.  That already caused
problems in the 90-ies, when moving scsi disks from one scsi host
adapter to another type, *way* before virtualization became a thing.

BTW:  One possible way to figure which LCHS layout a disk uses is to
check the MBR partition table.  With that we (a) don't need a new
interface between qemu and seabios and (b) it is not needed to manually
specify the geometry.

cheers,
  Gerd
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

> On 12 Jun 2019, at 16:06, Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
> On Wed, Jun 12, 2019 at 02:59:31PM +0300, Sam Eiderman wrote:
>> v1:
>> 
>> Non-standard logical geometries break under QEMU.
>> 
>> A virtual disk which contains an operating system which depends on
>> logical geometries (consistent values being reported from BIOS INT13
>> AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
>> logical geometries - for example 56 SPT (sectors per track).
>> No matter what QEMU will guess - SeaBIOS, for large enough disks - will
>> use LBA translation, which will report 63 SPT instead.
> 
> --verbose please.
> 
> As far I know seabios switches to LBA mode when the disk is simply too
> big for LCHS addressing.  So I fail to see which problem is solved by
> this.  If your guest needs LCHS, why do you assign a disk which can't
> be fully accessed using LCHS addressing?

The scenario is as follows:

A user has a disk with 56 spts.
This disk has been already created under a bios that reported 56 spts.
When migrating this disk to QEMU/SeaBIOS, SeaBIOS will report 63 spts
(under LBA translation) - this will break the boot for this guest.

> 
>> In addition we can not enforce SeaBIOS to rely on phyiscal geometries at
>> all. A virtio-blk-pci virtual disk with 255 phyiscal heads can not
>> report more than 16 physical heads when moved to an IDE controller, the
>> ATA spec allows a maximum of 16 heads - this is an artifact of
>> virtualization.
> 
> Well, not really.  Moving disks from one controller to another when the
> OS depends on LHCS addressing never is a good idea.  That already caused
> problems in the 90-ies, when moving scsi disks from one scsi host
> adapter to another type, *way* before virtualization became a thing.

I agree, but this is easily solvable in virtualized environments where the
hypervisor can guess the correct LCHS values by inspecting the MBR,
or letting the user set these values manually.

> 
> BTW:  One possible way to figure which LCHS layout a disk uses is to
> check the MBR partition table.  With that we (a) don't need a new
> interface between qemu and seabios and (b) it is not needed to manually
> specify the geometry.

In my opinion SeaBIOS is not the correct place for this change since
“enhancing” the detection of LCHS values in SeaBIOS may cause it to
suddenly report different values for already existing guests which rely on
LCHS - thus, breaking compatibility.
Much like smbios, acpi and mptables - I believe that the correct place to
use MBR guessing is QEMU (which already has one, with some issues)
and pass the guess using fw_cfg - this will allow using the compat system
in qemu itself.

Sam

> 
> cheers,
>  Gerd
> 
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

On Wed, Jun 12, 2019 at 04:30:03PM +0300, Sam Eiderman wrote:
> 
> 
> > On 12 Jun 2019, at 16:06, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > 
> > On Wed, Jun 12, 2019 at 02:59:31PM +0300, Sam Eiderman wrote:
> >> v1:
> >> 
> >> Non-standard logical geometries break under QEMU.
> >> 
> >> A virtual disk which contains an operating system which depends on
> >> logical geometries (consistent values being reported from BIOS INT13
> >> AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
> >> logical geometries - for example 56 SPT (sectors per track).
> >> No matter what QEMU will guess - SeaBIOS, for large enough disks - will
> >> use LBA translation, which will report 63 SPT instead.
> > 
> > --verbose please.
> > 
> > As far I know seabios switches to LBA mode when the disk is simply too
> > big for LCHS addressing.  So I fail to see which problem is solved by
> > this.  If your guest needs LCHS, why do you assign a disk which can't
> > be fully accessed using LCHS addressing?
> 
> The scenario is as follows:
> 
> A user has a disk with 56 spts.
> This disk has been already created under a bios that reported 56 spts.
> When migrating this disk to QEMU/SeaBIOS, SeaBIOS will report 63 spts
> (under LBA translation) - this will break the boot for this guest.

You sayed so already.  I was looking for a real world example.  Guests
which can't deal with LBA should be pretty rare these days.  What kind
of guest?  What other bios?  Or is this a purely theoretical issue?

> >> In addition we can not enforce SeaBIOS to rely on phyiscal geometries at
> >> all. A virtio-blk-pci virtual disk with 255 phyiscal heads can not
> >> report more than 16 physical heads when moved to an IDE controller, the
> >> ATA spec allows a maximum of 16 heads - this is an artifact of
> >> virtualization.
> > 
> > Well, not really.  Moving disks from one controller to another when the
> > OS depends on LHCS addressing never is a good idea.  That already caused
> > problems in the 90-ies, when moving scsi disks from one scsi host
> > adapter to another type, *way* before virtualization became a thing.
> 
> I agree, but this is easily solvable in virtualized environments where the
> hypervisor can guess the correct LCHS values by inspecting the MBR,

Yes.  This is exactly what the more clever scsi host adapter int13 rom
implementations ended up doing too.  Look at MBR to figure which LCHS
they should use.

> or letting the user set these values manually.

Why?  Asking the user to deal with the mess is pretty lame if there are
better options.  And IMO doing this fully automatic in seabios is
better.

> > BTW:  One possible way to figure which LCHS layout a disk uses is to
> > check the MBR partition table.  With that we (a) don't need a new
> > interface between qemu and seabios and (b) it is not needed to manually
> > specify the geometry.
> 
> In my opinion SeaBIOS is not the correct place for this change since
> “enhancing” the detection of LCHS values in SeaBIOS may cause it to
> suddenly report different values for already existing guests which rely on
> LCHS - thus, breaking compatibility.

I can't see how this can break guests.  It should either have no effect
(guests using LBA) or unbreak guests due to LCHS changing from "wrong"
to "correct".

cheers,
  Gerd
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

> On 12 Jun 2019, at 22:18, Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
> On Wed, Jun 12, 2019 at 04:30:03PM +0300, Sam Eiderman wrote:
>> 
>> 
>>> On 12 Jun 2019, at 16:06, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>> 
>>> On Wed, Jun 12, 2019 at 02:59:31PM +0300, Sam Eiderman wrote:
>>>> v1:
>>>> 
>>>> Non-standard logical geometries break under QEMU.
>>>> 
>>>> A virtual disk which contains an operating system which depends on
>>>> logical geometries (consistent values being reported from BIOS INT13
>>>> AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
>>>> logical geometries - for example 56 SPT (sectors per track).
>>>> No matter what QEMU will guess - SeaBIOS, for large enough disks - will
>>>> use LBA translation, which will report 63 SPT instead.
>>> 
>>> --verbose please.
>>> 
>>> As far I know seabios switches to LBA mode when the disk is simply too
>>> big for LCHS addressing.  So I fail to see which problem is solved by
>>> this.  If your guest needs LCHS, why do you assign a disk which can't
>>> be fully accessed using LCHS addressing?
>> 
>> The scenario is as follows:
>> 
>> A user has a disk with 56 spts.
>> This disk has been already created under a bios that reported 56 spts.
>> When migrating this disk to QEMU/SeaBIOS, SeaBIOS will report 63 spts
>> (under LBA translation) - this will break the boot for this guest.
> 
> You sayed so already.  I was looking for a real world example.  Guests
> which can't deal with LBA should be pretty rare these days.  What kind
> of guest?  What other bios?  Or is this a purely theoretical issue?

Yes they are pretty rare.
Windows 2000 and Windows XP guests migrated from VMware to Qemu/KVM
would not boot due to incorrect disk geometries (some had 32/56 spt instead of
56. Also number of heads was not entirely correct)

> 
>>>> In addition we can not enforce SeaBIOS to rely on phyiscal geometries at
>>>> all. A virtio-blk-pci virtual disk with 255 phyiscal heads can not
>>>> report more than 16 physical heads when moved to an IDE controller, the
>>>> ATA spec allows a maximum of 16 heads - this is an artifact of
>>>> virtualization.
>>> 
>>> Well, not really.  Moving disks from one controller to another when the
>>> OS depends on LHCS addressing never is a good idea.  That already caused
>>> problems in the 90-ies, when moving scsi disks from one scsi host
>>> adapter to another type, *way* before virtualization became a thing.
>> 
>> I agree, but this is easily solvable in virtualized environments where the
>> hypervisor can guess the correct LCHS values by inspecting the MBR,
> 
> Yes.  This is exactly what the more clever scsi host adapter int13 rom
> implementations ended up doing too.  Look at MBR to figure which LCHS
> they should use.
> 
>> or letting the user set these values manually.
> 
> Why?  Asking the user to deal with the mess is pretty lame if there are
> better options.  And IMO doing this fully automatic in seabios is
> better.

I’m not against an automatic approach, however I do think that doing this
in SeaBIOS might break compatibility for already existing guests that will
suddenly see different LCHS values. (Explanation below)

Notice that already today it is possible to pass “cyls", “heads", “sectors” and
even “chs-trans” (IDE only) for devices in QEMU, but these are only the
physical geometries of the disks which later on SeaBIOS might use to
determine the logical geometries.
"chs-trans" is an already existing PV interface between QEMU and
SeaBIOS for that matter (although it only supports 4 IDE disks).

I believe that the steps to bring this issue to a more stable state are:
Create a PV interface between QEMU and SeaBIOS to pass LCHS (Implemented here)
Allow users to manually set values for LCHS values in QEMU (Implemented here)
(Up until here, we do not break any existing functionality)
Implement a better LCHS guessing algorithm in QEMU - the existing ones contains some issues
On new machine versions - pass guessed LCHS directly to SeaBIOS
At the moment QEMU does not propagate its MBR guessed LCHS values, but only uses them to set PCHS values for disks - so SeaBIOS has to guess again
(Also here we will not break compatibility for older machine versions)

In addition, QEMU allows the use of VMDKs, some VMDK descriptors contain the following values:
    ddb.geometry.biosHeads = “16”
    ddb.geometry.biosHeads = “83257”
Which override the guessing algorithm in VMware and request the following values to be set.

Providing such PV interface will allow to support these VMDKs too.

> 
>>> BTW:  One possible way to figure which LCHS layout a disk uses is to
>>> check the MBR partition table.  With that we (a) don't need a new
>>> interface between qemu and seabios and (b) it is not needed to manually
>>> specify the geometry.
>> 
>> In my opinion SeaBIOS is not the correct place for this change since
>> “enhancing” the detection of LCHS values in SeaBIOS may cause it to
>> suddenly report different values for already existing guests which rely on
>> LCHS - thus, breaking compatibility.
> 
> I can't see how this can break guests.  It should either have no effect
> (guests using LBA) or unbreak guests due to LCHS changing from "wrong"
> to "correct”.

I’m not sure what do you mean by "unbreak guests” if you change an existing
guest that uses LCHS from 56 spt to LBA (63 spt) it will stop booting.
Your guessing algorithm will have to guess 56, if it will fail guessing 56 correctly,
the user can not perform any action beside downgrading SeaBIOS in order to run
the guest.

Sam

> 
> cheers,
>  Gerd

typo:
ddb.geometry.biosCylinders = “83257” *

Sam

> On 13 Jun 2019, at 10:41, Sam Eiderman <shmuel.eiderman@oracle.com> wrote:
> 
> 
> 
>> On 12 Jun 2019, at 22:18, Gerd Hoffmann <kraxel@redhat.com <mailto:kraxel@redhat.com>> wrote:
>> 
>> On Wed, Jun 12, 2019 at 04:30:03PM +0300, Sam Eiderman wrote:
>>> 
>>> 
>>>> On 12 Jun 2019, at 16:06, Gerd Hoffmann <kraxel@redhat.com <mailto:kraxel@redhat.com>> wrote:
>>>> 
>>>> On Wed, Jun 12, 2019 at 02:59:31PM +0300, Sam Eiderman wrote:
>>>>> v1:
>>>>> 
>>>>> Non-standard logical geometries break under QEMU.
>>>>> 
>>>>> A virtual disk which contains an operating system which depends on
>>>>> logical geometries (consistent values being reported from BIOS INT13
>>>>> AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
>>>>> logical geometries - for example 56 SPT (sectors per track).
>>>>> No matter what QEMU will guess - SeaBIOS, for large enough disks - will
>>>>> use LBA translation, which will report 63 SPT instead.
>>>> 
>>>> --verbose please.
>>>> 
>>>> As far I know seabios switches to LBA mode when the disk is simply too
>>>> big for LCHS addressing.  So I fail to see which problem is solved by
>>>> this.  If your guest needs LCHS, why do you assign a disk which can't
>>>> be fully accessed using LCHS addressing?
>>> 
>>> The scenario is as follows:
>>> 
>>> A user has a disk with 56 spts.
>>> This disk has been already created under a bios that reported 56 spts.
>>> When migrating this disk to QEMU/SeaBIOS, SeaBIOS will report 63 spts
>>> (under LBA translation) - this will break the boot for this guest.
>> 
>> You sayed so already.  I was looking for a real world example.  Guests
>> which can't deal with LBA should be pretty rare these days.  What kind
>> of guest?  What other bios?  Or is this a purely theoretical issue?
> 
> Yes they are pretty rare.
> Windows 2000 and Windows XP guests migrated from VMware to Qemu/KVM
> would not boot due to incorrect disk geometries (some had 32/56 spt instead of
> 56. Also number of heads was not entirely correct)
> 
>> 
>>>>> In addition we can not enforce SeaBIOS to rely on phyiscal geometries at
>>>>> all. A virtio-blk-pci virtual disk with 255 phyiscal heads can not
>>>>> report more than 16 physical heads when moved to an IDE controller, the
>>>>> ATA spec allows a maximum of 16 heads - this is an artifact of
>>>>> virtualization.
>>>> 
>>>> Well, not really.  Moving disks from one controller to another when the
>>>> OS depends on LHCS addressing never is a good idea.  That already caused
>>>> problems in the 90-ies, when moving scsi disks from one scsi host
>>>> adapter to another type, *way* before virtualization became a thing.
>>> 
>>> I agree, but this is easily solvable in virtualized environments where the
>>> hypervisor can guess the correct LCHS values by inspecting the MBR,
>> 
>> Yes.  This is exactly what the more clever scsi host adapter int13 rom
>> implementations ended up doing too.  Look at MBR to figure which LCHS
>> they should use.
>> 
>>> or letting the user set these values manually.
>> 
>> Why?  Asking the user to deal with the mess is pretty lame if there are
>> better options.  And IMO doing this fully automatic in seabios is
>> better.
> 
> I’m not against an automatic approach, however I do think that doing this
> in SeaBIOS might break compatibility for already existing guests that will
> suddenly see different LCHS values. (Explanation below)
> 
> Notice that already today it is possible to pass “cyls", “heads", “sectors” and
> even “chs-trans” (IDE only) for devices in QEMU, but these are only the
> physical geometries of the disks which later on SeaBIOS might use to
> determine the logical geometries.
> "chs-trans" is an already existing PV interface between QEMU and
> SeaBIOS for that matter (although it only supports 4 IDE disks).
> 
> I believe that the steps to bring this issue to a more stable state are:
> Create a PV interface between QEMU and SeaBIOS to pass LCHS (Implemented here)
> Allow users to manually set values for LCHS values in QEMU (Implemented here)
> (Up until here, we do not break any existing functionality)
> Implement a better LCHS guessing algorithm in QEMU - the existing ones contains some issues
> On new machine versions - pass guessed LCHS directly to SeaBIOS
> At the moment QEMU does not propagate its MBR guessed LCHS values, but only uses them to set PCHS values for disks - so SeaBIOS has to guess again
> (Also here we will not break compatibility for older machine versions)
> 
> In addition, QEMU allows the use of VMDKs, some VMDK descriptors contain the following values:
>     ddb.geometry.biosHeads = “16”
>     ddb.geometry.biosHeads = “83257”
> Which override the guessing algorithm in VMware and request the following values to be set.
> 
> Providing such PV interface will allow to support these VMDKs too.
> 
>> 
>>>> BTW:  One possible way to figure which LCHS layout a disk uses is to
>>>> check the MBR partition table.  With that we (a) don't need a new
>>>> interface between qemu and seabios and (b) it is not needed to manually
>>>> specify the geometry.
>>> 
>>> In my opinion SeaBIOS is not the correct place for this change since
>>> “enhancing” the detection of LCHS values in SeaBIOS may cause it to
>>> suddenly report different values for already existing guests which rely on
>>> LCHS - thus, breaking compatibility.
>> 
>> I can't see how this can break guests.  It should either have no effect
>> (guests using LBA) or unbreak guests due to LCHS changing from "wrong"
>> to "correct”.
> 
> I’m not sure what do you mean by "unbreak guests” if you change an existing
> guest that uses LCHS from 56 spt to LBA (63 spt) it will stop booting.
> Your guessing algorithm will have to guess 56, if it will fail guessing 56 correctly,
> the user can not perform any action beside downgrading SeaBIOS in order to run
> the guest.
> 
> Sam
> 
>> 
>> cheers,
>>  Gerd

_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

  Hi,

> Yes they are pretty rare.
> Windows 2000 and Windows XP guests migrated from VMware to Qemu/KVM
> would not boot due to incorrect disk geometries (some had 32/56 spt instead of
> 56. Also number of heads was not entirely correct)

Ok.

> > Why?  Asking the user to deal with the mess is pretty lame if there are
> > better options.  And IMO doing this fully automatic in seabios is
> > better.
> 
> I’m not against an automatic approach, however I do think that doing this
> in SeaBIOS might break compatibility for already existing guests that will
> suddenly see different LCHS values. (Explanation below)

> > I can't see how this can break guests.  It should either have no effect
> > (guests using LBA) or unbreak guests due to LCHS changing from "wrong"
> > to "correct”.
> 
> I’m not sure what do you mean by "unbreak guests” if you change an existing
> guest that uses LCHS from 56 spt to LBA (63 spt) it will stop booting.

Well, that LCHS change happens because you move the guest from vmware to
qemu and seabios uses 63 spt no matter what if the disk is too big for
chs addressing.

When seabios is changed to look at the MBR to figure what the lchs of
the disk is that will make your guest boot.

> Your guessing algorithm will have to guess 56, if it will fail guessing 56 correctly,
> the user can not perform any action beside downgrading SeaBIOS in order to run
> the guest.

Sure, if the guess is wrong then the guest will not boot.  That isn't
worse than the situation we have today where seabios will not even try
to figure what the lchs of the disk is.

And, no, downgrading seabios will not make your vmware guest with 56 spt
boot.

cheers,
  Gerd
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

> On 13 Jun 2019, at 12:38, Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
>  Hi,
> 
>> Yes they are pretty rare.
>> Windows 2000 and Windows XP guests migrated from VMware to Qemu/KVM
>> would not boot due to incorrect disk geometries (some had 32/56 spt instead of
>> 56. Also number of heads was not entirely correct)
> 
> Ok.
> 
>>> Why?  Asking the user to deal with the mess is pretty lame if there are
>>> better options.  And IMO doing this fully automatic in seabios is
>>> better.
>> 
>> I’m not against an automatic approach, however I do think that doing this
>> in SeaBIOS might break compatibility for already existing guests that will
>> suddenly see different LCHS values. (Explanation below)
> 
>>> I can't see how this can break guests.  It should either have no effect
>>> (guests using LBA) or unbreak guests due to LCHS changing from "wrong"
>>> to "correct”.
>> 
>> I’m not sure what do you mean by "unbreak guests” if you change an existing
>> guest that uses LCHS from 56 spt to LBA (63 spt) it will stop booting.
> 
> Well, that LCHS change happens because you move the guest from vmware to
> qemu and seabios uses 63 spt no matter what if the disk is too big for
> chs addressing.
> 
> When seabios is changed to look at the MBR to figure what the lchs of
> the disk is that will make your guest boot.

See below

> 
>> Your guessing algorithm will have to guess 56, if it will fail guessing 56 correctly,
>> the user can not perform any action beside downgrading SeaBIOS in order to run
>> the guest.
> 
> Sure, if the guess is wrong then the guest will not boot.  That isn't
> worse than the situation we have today where seabios will not even try
> to figure what the lchs of the disk is.
> 
> And, no, downgrading seabios will not make your vmware guest with 56 spt
> boot.

I’m not talking about the vmware case here.
If you introduce MBR guessing into SeaBIOS and change its default behaviour you
risk making operating systems such as Windows XP / 2003 / 2000 created on
QEMU to not work anymore.

Example:

	Consider a Windows XP that works with the following geometries on standard
	QEMU/SeaBIOS today:
	
	Disk is very large, therefore INT13 AH=02:

		255 heads, 63 spt

	Now you change SeaBIOS to guess from the MBR.
	In some cases the MBR guess can be incorrect so now SeaBIOS will guess:

		255 heads, 62 spt

	The guest no longer boots with these geometries and you broke compatibility.
	
Can there be a guest that will fail the MBR in such a way? Yes.
Look at the following MBR partition table of a Windows XP guest in our production
environment:

Disk size in sectors: 16777216

Binary (only one partition 16 bytes): 80 01 01 00 07 fe ff ff 3f 00 00 00 d5 ea ff 00
Start: (0, 1, 1, 63)
End: (1023, 254, 63, 16771859)

As can be easily seen, any MBR guessing algorithm should guess:

	255 heads (since a value of 254 appears), 63 spt (since a value of 63 appears)

Turns out that this image does not work with 255, 63 but actually requires

	16 heads, 63 spt

to boot.

So relying on MBR partitions alone is not always enough and sometimes manual intervention
is required.

(VMware solves this by specifying 16 heads, 63 spt in the descriptor file and overrides its
default guessing algorithm which also fails here)

(By the way this is not a VMware specific problem, the disk itself was imported to VMware in
a P2V scenario, so that probably explains why the ddb.geometry.bios* values appear in the
VMDK in the first place)


> 
> cheers,
>  Gerd
> 

_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

  Hi,

> Can there be a guest that will fail the MBR in such a way? Yes.
> Look at the following MBR partition table of a Windows XP guest in our production
> environment:
> 
> Disk size in sectors: 16777216
> 
> Binary (only one partition 16 bytes): 80 01 01 00 07 fe ff ff 3f 00 00 00 d5 ea ff 00
> Start: (0, 1, 1, 63)
> End: (1023, 254, 63, 16771859)
> 
> As can be easily seen, any MBR guessing algorithm should guess:
> 
> 	255 heads (since a value of 254 appears), 63 spt (since a value of 63 appears)
> 
> Turns out that this image does not work with 255, 63 but actually requires
> 
> 	16 heads, 63 spt
> 
> to boot.
> 
> So relying on MBR partitions alone is not always enough and sometimes manual intervention
> is required.

Ok, given that seabios has no setup any manual configuration needs to be done via qemu.

But why do we need a new interface for that?  IDE can pass the geometry
to the guest.  virtio-blk has support too (VIRTIO_BLK_F_GEOMETRY).
Likewise scsi (MODE_PAGE_HD_GEOMETRY).  So this should be doable without
any qemu changes.

cheers,
  Gerd
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

> On 14 Jun 2019, at 7:43, Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
>  Hi,
> 
>> Can there be a guest that will fail the MBR in such a way? Yes.
>> Look at the following MBR partition table of a Windows XP guest in our production
>> environment:
>> 
>> Disk size in sectors: 16777216
>> 
>> Binary (only one partition 16 bytes): 80 01 01 00 07 fe ff ff 3f 00 00 00 d5 ea ff 00
>> Start: (0, 1, 1, 63)
>> End: (1023, 254, 63, 16771859)
>> 
>> As can be easily seen, any MBR guessing algorithm should guess:
>> 
>> 	255 heads (since a value of 254 appears), 63 spt (since a value of 63 appears)
>> 
>> Turns out that this image does not work with 255, 63 but actually requires
>> 
>> 	16 heads, 63 spt
>> 
>> to boot.
>> 
>> So relying on MBR partitions alone is not always enough and sometimes manual intervention
>> is required.
> 
> Ok, given that seabios has no setup any manual configuration needs to be done via qemu.
> 
> But why do we need a new interface for that?  IDE can pass the geometry
> to the guest.  virtio-blk has support too (VIRTIO_BLK_F_GEOMETRY).
> Likewise scsi (MODE_PAGE_HD_GEOMETRY).  So this should be doable without
> any qemu changes.

This was indeed considered (all 3 methods) but it has the following issues:

Physical geometries of devices must now also be logical geometries with translation=none.
When the OS will query these devices - It will now see different physical geometries, adapted to be logical geometries.
I’m not sure even how to implement this without breaking existing compatibility - since we don’t want to affect logical geometries of currently used guests.
MODE_PAGE_HD_GEOMETRY does not contain the spts, only cylinders (as 3 byte number) and heads (as 1 byte number) and computes the spts using: number_of_total_sectors / (heads * cylinders), this means that qemu now must report number_of_total_sectors as heads * cylinders * spt for SeaBIOS to correctly receive the number of spts - this is not optimal since number_of_total_sectors can not reflect the real amount of sectors in the disk which should be reported from CDB_CMD_READ_CAPACITY.
Moving a scsi-hd/virtio-blk with 255 physical heads to ide-hd, we will still need to report 255 heads - this is possible since a whole byte can be used in the “ide identify” command, but goes against the spec of a maximum of 16 heads for IDE.

Overall this approach is much more complicated.

Sam

> 
> cheers,
>  Gerd
> 

_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

  Hi,

> > Ok, given that seabios has no setup any manual configuration needs to be done via qemu.
> > 
> > But why do we need a new interface for that?  IDE can pass the geometry
> > to the guest.  virtio-blk has support too (VIRTIO_BLK_F_GEOMETRY).
> > Likewise scsi (MODE_PAGE_HD_GEOMETRY).  So this should be doable without
> > any qemu changes.
> 
> This was indeed considered (all 3 methods) but it has the following issues:
> 
> Physical geometries of devices must now also be logical geometries with translation=none.

Yes.

> When the OS will query these devices - It will now see different physical geometries, adapted to be logical geometries.

Yes.

> I’m not sure even how to implement this without breaking existing
> compatibility - since we don’t want to affect logical geometries of
> currently used guests.

We can copy the logic which calculates lchs from seabios to qemu and use
it for pchs.

The tricky part of this is how to do the switch without requiring a
lockstep update of seabios and qemu.  seabios can't easily know whenever
it should use the current logic (current qemu) or whenever it should
simply use pchs with translation=none (updated qemu).

Hmm ...

> MODE_PAGE_HD_GEOMETRY does not contain the spts, only cylinders (as 3
> byte number) and heads (as 1 byte number) and computes the spts using:

Well, there also is MODE_PAGE_FLEXIBLE_DISK_GEOMETRY.

> Moving a scsi-hd/virtio-blk with 255 physical heads to ide-hd, we will
> still need to report 255 heads - this is possible since a whole byte
> can be used in the “ide identify” command, but goes against the spec
> of a maximum of 16 heads for IDE.

Why do you want migrate _to_ IDE?

> Overall this approach is much more complicated.

Well, adding new fw_cfg interfaces has a long term maintenance cost.
So there should be a pretty good reason for them.

cheers,
  Gerd
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

> On 17 Jun 2019, at 9:50, Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
>  Hi,
> 
>>> Ok, given that seabios has no setup any manual configuration needs to be done via qemu.
>>> 
>>> But why do we need a new interface for that?  IDE can pass the geometry
>>> to the guest.  virtio-blk has support too (VIRTIO_BLK_F_GEOMETRY).
>>> Likewise scsi (MODE_PAGE_HD_GEOMETRY).  So this should be doable without
>>> any qemu changes.
>> 
>> This was indeed considered (all 3 methods) but it has the following issues:
>> 
>> Physical geometries of devices must now also be logical geometries with translation=none.
> 
> Yes.
> 
>> When the OS will query these devices - It will now see different physical geometries, adapted to be logical geometries.
> 
> Yes.
> 
>> I’m not sure even how to implement this without breaking existing
>> compatibility - since we don’t want to affect logical geometries of
>> currently used guests.
> 
> We can copy the logic which calculates lchs from seabios to qemu and use
> it for pchs.
> 
> The tricky part of this is how to do the switch without requiring a
> lockstep update of seabios and qemu.  seabios can't easily know whenever
> it should use the current logic (current qemu) or whenever it should
> simply use pchs with translation=none (updated qemu).
> 
> Hmm ...
> 
>> MODE_PAGE_HD_GEOMETRY does not contain the spts, only cylinders (as 3
>> byte number) and heads (as 1 byte number) and computes the spts using:
> 
> Well, there also is MODE_PAGE_FLEXIBLE_DISK_GEOMETRY.
> 
>> Moving a scsi-hd/virtio-blk with 255 physical heads to ide-hd, we will
>> still need to report 255 heads - this is possible since a whole byte
>> can be used in the “ide identify” command, but goes against the spec
>> of a maximum of 16 heads for IDE.
> 
> Why do you want migrate _to_ IDE?

Even without migration, now under SeaBIOS probably most IDE disks
report 255 heads and 63 spts due to LBA translation, while exposing
up to 16 physical heads (IDE spec).
So you can’t really report in ATA identify command your wanted logical
heads (255).

This can be solved in a very complicated way:

For virtio-blk disks - report bios geometries as physical geometries.
This might break current compatibility (showing different physical geometries)
For scsi disks - report bios geometries as physical geometries.
Implement MODE_PAGE_FLEXIBLE_DISK_GEOMETRY and translation=none - this new interface will help with compatibility
For IDE disks - specially craft valid physical geometries (heads <= 16) with a specific translation,
This is super complicated, for example to make an IDE disk report lchs of 32 heads, 56 spts, you need a physical geometry of 16 heads, 56 spts and report 2046 cylinders with a "large" translation - which will effectively cut down the number of cylinders by 2 to 1023 and multiply the heads by 2 to 32, achieving the desired lchs. Also we can not even make an IDE report 255 heads with 56 spts with any translation (this is an actual value from production) - so the disk must be moved to scsi-hd/virtio-blk - which also breaks compatibility.

This implementation creates 3 different non conventional (PV) ways of reporting lchs directly between Qemu and SeaBIOS - which add a lot of technical depth for resolving a legacy issue. A fw-cfg value named “bootdevices” (or “bios-geometry”) is much more straightforward and makes it more readable/explicit.

WDYT?

> 
>> Overall this approach is much more complicated.
> 
> Well, adding new fw_cfg interfaces has a long term maintenance cost.
> So there should be a pretty good reason for them.
> 
> cheers,
>  Gerd
> 

_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org