* [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface @ 2019-06-12 11:59 Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 1/8] block: Refactor macros - fix tabbing Sam Eiderman ` (10 more replies) 0 siblings, 11 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-12 11:59 UTC (permalink / raw) To: kwolf, qemu-block, qemu-devel, mreitz, seabios, kraxel, kevin Cc: liran.alon, shmuel.eiderman, karl.heubaum, arbel.moshe 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Qemu-devel] [QEMU] [PATCH v2 1/8] block: Refactor macros - fix tabbing 2019-06-12 11:59 [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface Sam Eiderman @ 2019-06-12 11:59 ` Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 2/8] block: Support providing LCHS from user Sam Eiderman ` (9 subsequent siblings) 10 siblings, 0 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-12 11:59 UTC (permalink / raw) To: kwolf, qemu-block, qemu-devel, mreitz, seabios, kraxel, kevin Cc: liran.alon, shmuel.eiderman, karl.heubaum, arbel.moshe Fixing tabbing in block related macros. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> --- hw/ide/qdev.c | 2 +- include/hw/block/block.h | 16 ++++++++-------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c index 360cd20bd8..9cae3205df 100644 --- a/hw/ide/qdev.c +++ b/hw/ide/qdev.c @@ -285,7 +285,7 @@ static void ide_drive_realize(IDEDevice *dev, Error **errp) DEFINE_BLOCK_PROPERTIES(IDEDrive, dev.conf), \ DEFINE_BLOCK_ERROR_PROPERTIES(IDEDrive, dev.conf), \ DEFINE_PROP_STRING("ver", IDEDrive, dev.version), \ - DEFINE_PROP_UINT64("wwn", IDEDrive, dev.wwn, 0), \ + DEFINE_PROP_UINT64("wwn", IDEDrive, dev.wwn, 0), \ DEFINE_PROP_STRING("serial", IDEDrive, dev.serial),\ DEFINE_PROP_STRING("model", IDEDrive, dev.model) diff --git a/include/hw/block/block.h b/include/hw/block/block.h index 607539057a..fd55a30bca 100644 --- a/include/hw/block/block.h +++ b/include/hw/block/block.h @@ -50,21 +50,21 @@ static inline unsigned int get_physical_block_exp(BlockConf *conf) _conf.logical_block_size), \ DEFINE_PROP_BLOCKSIZE("physical_block_size", _state, \ _conf.physical_block_size), \ - DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0), \ + DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0), \ DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0), \ - DEFINE_PROP_UINT32("discard_granularity", _state, \ - _conf.discard_granularity, -1), \ - DEFINE_PROP_ON_OFF_AUTO("write-cache", _state, _conf.wce, \ - ON_OFF_AUTO_AUTO), \ + DEFINE_PROP_UINT32("discard_granularity", _state, \ + _conf.discard_granularity, -1), \ + DEFINE_PROP_ON_OFF_AUTO("write-cache", _state, _conf.wce, \ + ON_OFF_AUTO_AUTO), \ DEFINE_PROP_BOOL("share-rw", _state, _conf.share_rw, false) #define DEFINE_BLOCK_PROPERTIES(_state, _conf) \ DEFINE_PROP_DRIVE("drive", _state, _conf.blk), \ DEFINE_BLOCK_PROPERTIES_BASE(_state, _conf) -#define DEFINE_BLOCK_CHS_PROPERTIES(_state, _conf) \ - DEFINE_PROP_UINT32("cyls", _state, _conf.cyls, 0), \ - DEFINE_PROP_UINT32("heads", _state, _conf.heads, 0), \ +#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) #define DEFINE_BLOCK_ERROR_PROPERTIES(_state, _conf) \ -- 2.13.3 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [Qemu-devel] [QEMU] [PATCH v2 2/8] block: Support providing LCHS from user 2019-06-12 11:59 [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 1/8] block: Refactor macros - fix tabbing Sam Eiderman @ 2019-06-12 11:59 ` Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 3/8] bootdevice: Add interface to gather LCHS Sam Eiderman ` (8 subsequent siblings) 10 siblings, 0 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-12 11:59 UTC (permalink / raw) To: kwolf, qemu-block, qemu-devel, mreitz, seabios, kraxel, kevin Cc: liran.alon, shmuel.eiderman, karl.heubaum, arbel.moshe Add logical geometry variables to BlockConf. A user can now supply "lcyls", "lheads" & "lsecs" for any HD device that supports CHS ("cyls", "heads", "secs"). These devices include: * ide-hd * scsi-hd * virtio-blk-pci In future commits we will use the provided LCHS and pass it to the BIOS through fw_cfg to be supplied using INT13 routines. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> --- include/hw/block/block.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/include/hw/block/block.h b/include/hw/block/block.h index fd55a30bca..d7246f3862 100644 --- a/include/hw/block/block.h +++ b/include/hw/block/block.h @@ -26,6 +26,7 @@ typedef struct BlockConf { uint32_t discard_granularity; /* geometry, not all devices use this */ uint32_t cyls, heads, secs; + uint32_t lcyls, lheads, lsecs; OnOffAuto wce; bool share_rw; BlockdevOnError rerror; @@ -65,7 +66,10 @@ static inline unsigned int get_physical_block_exp(BlockConf *conf) #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) + DEFINE_PROP_UINT32("secs", _state, _conf.secs, 0), \ + DEFINE_PROP_UINT32("lcyls", _state, _conf.lcyls, 0), \ + DEFINE_PROP_UINT32("lheads", _state, _conf.lheads, 0), \ + DEFINE_PROP_UINT32("lsecs", _state, _conf.lsecs, 0) #define DEFINE_BLOCK_ERROR_PROPERTIES(_state, _conf) \ DEFINE_PROP_BLOCKDEV_ON_ERROR("rerror", _state, _conf.rerror, \ -- 2.13.3 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [Qemu-devel] [QEMU] [PATCH v2 3/8] bootdevice: Add interface to gather LCHS 2019-06-12 11:59 [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 1/8] block: Refactor macros - fix tabbing Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 2/8] block: Support providing LCHS from user Sam Eiderman @ 2019-06-12 11:59 ` Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 4/8] scsi: Propagate unrealize() callback to scsi-hd Sam Eiderman ` (7 subsequent siblings) 10 siblings, 0 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-12 11:59 UTC (permalink / raw) To: kwolf, qemu-block, qemu-devel, mreitz, seabios, kraxel, kevin Cc: liran.alon, shmuel.eiderman, karl.heubaum, arbel.moshe Add an interface to provide direct logical CHS values for boot devices. We will use this interface in the next commits. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> --- bootdevice.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++ include/sysemu/sysemu.h | 3 +++ 2 files changed, 58 insertions(+) diff --git a/bootdevice.c b/bootdevice.c index 1d225202f9..bc5e1c2de4 100644 --- a/bootdevice.c +++ b/bootdevice.c @@ -343,3 +343,58 @@ void device_add_bootindex_property(Object *obj, int32_t *bootindex, /* initialize devices' bootindex property to -1 */ object_property_set_int(obj, -1, name, NULL); } + +typedef struct FWLCHSEntry FWLCHSEntry; + +struct FWLCHSEntry { + QTAILQ_ENTRY(FWLCHSEntry) link; + DeviceState *dev; + char *suffix; + uint32_t lcyls; + uint32_t lheads; + uint32_t lsecs; +}; + +static QTAILQ_HEAD(, FWLCHSEntry) fw_lchs = + QTAILQ_HEAD_INITIALIZER(fw_lchs); + +void add_boot_device_lchs(DeviceState *dev, const char *suffix, + uint32_t lcyls, uint32_t lheads, uint32_t lsecs) +{ + FWLCHSEntry *node; + + if (!lcyls && !lheads && !lsecs) { + return; + } + + assert(dev != NULL || suffix != NULL); + + node = g_malloc0(sizeof(FWLCHSEntry)); + node->suffix = g_strdup(suffix); + node->dev = dev; + node->lcyls = lcyls; + node->lheads = lheads; + node->lsecs = lsecs; + + QTAILQ_INSERT_TAIL(&fw_lchs, node, link); +} + +void del_boot_device_lchs(DeviceState *dev, const char *suffix) +{ + FWLCHSEntry *i; + + if (dev == NULL) { + return; + } + + QTAILQ_FOREACH(i, &fw_lchs, link) { + if ((!suffix || !g_strcmp0(i->suffix, suffix)) && + i->dev == dev) { + QTAILQ_REMOVE(&fw_lchs, i, link); + g_free(i->suffix); + g_free(i); + + break; + } + } +} diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h index 61579ae71e..173dfbb539 100644 --- a/include/sysemu/sysemu.h +++ b/include/sysemu/sysemu.h @@ -171,6 +171,9 @@ void device_add_bootindex_property(Object *obj, int32_t *bootindex, DeviceState *dev, Error **errp); void restore_boot_order(void *opaque); void validate_bootdevices(const char *devices, Error **errp); +void add_boot_device_lchs(DeviceState *dev, const char *suffix, + uint32_t lcyls, uint32_t lheads, uint32_t lsecs); +void del_boot_device_lchs(DeviceState *dev, const char *suffix); /* handler to set the boot_device order for a specific type of MachineClass */ typedef void QEMUBootSetHandler(void *opaque, const char *boot_order, -- 2.13.3 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [Qemu-devel] [QEMU] [PATCH v2 4/8] scsi: Propagate unrealize() callback to scsi-hd 2019-06-12 11:59 [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface Sam Eiderman ` (2 preceding siblings ...) 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 3/8] bootdevice: Add interface to gather LCHS Sam Eiderman @ 2019-06-12 11:59 ` Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 5/8] bootdevice: Gather LCHS from all relevant devices Sam Eiderman ` (6 subsequent siblings) 10 siblings, 0 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-12 11:59 UTC (permalink / raw) To: kwolf, qemu-block, qemu-devel, mreitz, seabios, kraxel, kevin Cc: liran.alon, shmuel.eiderman, karl.heubaum, arbel.moshe We will need to add LCHS removal logic to scsi-hd's unrealize() in the next commit. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> --- hw/scsi/scsi-bus.c | 15 +++++++++++++++ include/hw/scsi/scsi.h | 1 + 2 files changed, 16 insertions(+) diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c index c480553083..f6fe497a1a 100644 --- a/hw/scsi/scsi-bus.c +++ b/hw/scsi/scsi-bus.c @@ -55,6 +55,14 @@ static void scsi_device_realize(SCSIDevice *s, Error **errp) } } +static void scsi_device_unrealize(SCSIDevice *s, Error **errp) +{ + SCSIDeviceClass *sc = SCSI_DEVICE_GET_CLASS(s); + if (sc->unrealize) { + sc->unrealize(s, errp); + } +} + int scsi_bus_parse_cdb(SCSIDevice *dev, SCSICommand *cmd, uint8_t *buf, void *hba_private) { @@ -213,11 +221,18 @@ static void scsi_qdev_realize(DeviceState *qdev, Error **errp) static void scsi_qdev_unrealize(DeviceState *qdev, Error **errp) { SCSIDevice *dev = SCSI_DEVICE(qdev); + Error *local_err = NULL; if (dev->vmsentry) { qemu_del_vm_change_state_handler(dev->vmsentry); } + scsi_device_unrealize(dev, &local_err); + if (local_err) { + error_propagate(errp, local_err); + return; + } + scsi_device_purge_requests(dev, SENSE_CODE(NO_SENSE)); blockdev_mark_auto_del(dev->conf.blk); } diff --git a/include/hw/scsi/scsi.h b/include/hw/scsi/scsi.h index 426566a5c6..8cf71f910d 100644 --- a/include/hw/scsi/scsi.h +++ b/include/hw/scsi/scsi.h @@ -59,6 +59,7 @@ struct SCSIRequest { typedef struct SCSIDeviceClass { DeviceClass parent_class; void (*realize)(SCSIDevice *dev, Error **errp); + void (*unrealize)(SCSIDevice *dev, Error **errp); int (*parse_cdb)(SCSIDevice *dev, SCSICommand *cmd, uint8_t *buf, void *hba_private); SCSIRequest *(*alloc_req)(SCSIDevice *s, uint32_t tag, uint32_t lun, -- 2.13.3 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [Qemu-devel] [QEMU] [PATCH v2 5/8] bootdevice: Gather LCHS from all relevant devices 2019-06-12 11:59 [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface Sam Eiderman ` (3 preceding siblings ...) 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 4/8] scsi: Propagate unrealize() callback to scsi-hd Sam Eiderman @ 2019-06-12 11:59 ` Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 6/8] bootdevice: Refactor get_boot_devices_list Sam Eiderman ` (5 subsequent siblings) 10 siblings, 0 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-12 11:59 UTC (permalink / raw) To: kwolf, qemu-block, qemu-devel, mreitz, seabios, kraxel, kevin Cc: liran.alon, shmuel.eiderman, karl.heubaum, arbel.moshe Relevant devices are: * ide-hd (and ide-cd, ide-drive) * scsi-hd (and scsi-cd, scsi-disk, scsi-block) * virtio-blk-pci We do not call del_boot_device_lchs() for ide-* since we don't need to - IDE block devices do not support unplugging. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> --- hw/block/virtio-blk.c | 6 ++++++ hw/ide/qdev.c | 5 +++++ hw/scsi/scsi-disk.c | 14 ++++++++++++++ 3 files changed, 25 insertions(+) diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index 06e57a4d39..787bbd768a 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -1182,6 +1182,11 @@ static void virtio_blk_device_realize(DeviceState *dev, Error **errp) blk_set_guest_block_size(s->blk, s->conf.conf.logical_block_size); blk_iostatus_enable(s->blk); + + add_boot_device_lchs(dev, "/disk@0,0", + (&conf->conf)->lcyls, + (&conf->conf)->lheads, + (&conf->conf)->lsecs); } static void virtio_blk_device_unrealize(DeviceState *dev, Error **errp) @@ -1189,6 +1194,7 @@ static void virtio_blk_device_unrealize(DeviceState *dev, Error **errp) VirtIODevice *vdev = VIRTIO_DEVICE(dev); VirtIOBlock *s = VIRTIO_BLK(dev); + del_boot_device_lchs(dev, "/disk@0,0"); virtio_blk_data_plane_destroy(s->dataplane); s->dataplane = NULL; qemu_del_vm_change_state_handler(s->change); diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c index 9cae3205df..07f429d5e3 100644 --- a/hw/ide/qdev.c +++ b/hw/ide/qdev.c @@ -215,6 +215,11 @@ static void ide_dev_initfn(IDEDevice *dev, IDEDriveKind kind, Error **errp) add_boot_device_path(dev->conf.bootindex, &dev->qdev, dev->unit ? "/disk@1" : "/disk@0"); + + add_boot_device_lchs(&dev->qdev, dev->unit ? "/disk@1" : "/disk@0", + (&dev->conf)->lcyls, + (&dev->conf)->lheads, + (&dev->conf)->lsecs); } static void ide_dev_get_bootindex(Object *obj, Visitor *v, const char *name, diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c index 7b89ac798b..3451aefdea 100644 --- a/hw/scsi/scsi-disk.c +++ b/hw/scsi/scsi-disk.c @@ -2390,6 +2390,16 @@ static void scsi_realize(SCSIDevice *dev, Error **errp) blk_set_guest_block_size(s->qdev.conf.blk, s->qdev.blocksize); blk_iostatus_enable(s->qdev.conf.blk); + + add_boot_device_lchs(&dev->qdev, NULL, + (&dev->conf)->lcyls, + (&dev->conf)->lheads, + (&dev->conf)->lsecs); +} + +static void scsi_unrealize(SCSIDevice *dev, Error **errp) +{ + del_boot_device_lchs(&dev->qdev, NULL); } static void scsi_hd_realize(SCSIDevice *dev, Error **errp) @@ -2988,6 +2998,7 @@ static void scsi_hd_class_initfn(ObjectClass *klass, void *data) SCSIDeviceClass *sc = SCSI_DEVICE_CLASS(klass); sc->realize = scsi_hd_realize; + sc->unrealize = scsi_unrealize; sc->alloc_req = scsi_new_request; sc->unit_attention_reported = scsi_disk_unit_attention_reported; dc->desc = "virtual SCSI disk"; @@ -3019,6 +3030,7 @@ static void scsi_cd_class_initfn(ObjectClass *klass, void *data) SCSIDeviceClass *sc = SCSI_DEVICE_CLASS(klass); sc->realize = scsi_cd_realize; + sc->unrealize = scsi_unrealize; sc->alloc_req = scsi_new_request; sc->unit_attention_reported = scsi_disk_unit_attention_reported; dc->desc = "virtual SCSI CD-ROM"; @@ -3054,6 +3066,7 @@ static void scsi_block_class_initfn(ObjectClass *klass, void *data) SCSIDiskClass *sdc = SCSI_DISK_BASE_CLASS(klass); sc->realize = scsi_block_realize; + sc->unrealize = scsi_unrealize; sc->alloc_req = scsi_block_new_request; sc->parse_cdb = scsi_block_parse_cdb; sdc->dma_readv = scsi_block_dma_readv; @@ -3095,6 +3108,7 @@ static void scsi_disk_class_initfn(ObjectClass *klass, void *data) SCSIDeviceClass *sc = SCSI_DEVICE_CLASS(klass); sc->realize = scsi_disk_realize; + sc->unrealize = scsi_unrealize; sc->alloc_req = scsi_new_request; sc->unit_attention_reported = scsi_disk_unit_attention_reported; dc->fw_name = "disk"; -- 2.13.3 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [Qemu-devel] [QEMU] [PATCH v2 6/8] bootdevice: Refactor get_boot_devices_list 2019-06-12 11:59 [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface Sam Eiderman ` (4 preceding siblings ...) 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 5/8] bootdevice: Gather LCHS from all relevant devices Sam Eiderman @ 2019-06-12 11:59 ` Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values Sam Eiderman ` (4 subsequent siblings) 10 siblings, 0 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-12 11:59 UTC (permalink / raw) To: kwolf, qemu-block, qemu-devel, mreitz, seabios, kraxel, kevin Cc: liran.alon, shmuel.eiderman, karl.heubaum, arbel.moshe Move device name construction to a separate function. We will reuse this function in the following commit to pass logical CHS parameters through fw_cfg much like we currently pass bootindex. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> --- bootdevice.c | 61 +++++++++++++++++++++++++++++++++--------------------------- 1 file changed, 34 insertions(+), 27 deletions(-) diff --git a/bootdevice.c b/bootdevice.c index bc5e1c2de4..2b12fb85a4 100644 --- a/bootdevice.c +++ b/bootdevice.c @@ -202,6 +202,39 @@ DeviceState *get_boot_device(uint32_t position) return res; } +static char *get_boot_device_path(DeviceState *dev, bool ignore_suffixes, + char *suffix) +{ + char *devpath = NULL, *s = NULL, *d, *bootpath; + + if (dev) { + devpath = qdev_get_fw_dev_path(dev); + assert(devpath); + } + + if (!ignore_suffixes) { + if (dev) { + d = qdev_get_own_fw_dev_path_from_handler(dev->parent_bus, dev); + if (d) { + assert(!suffix); + s = d; + } else { + s = g_strdup(suffix); + } + } else { + s = g_strdup(suffix); + } + } + + bootpath = g_strdup_printf("%s%s", + devpath ? devpath : "", + s ? s : ""); + g_free(devpath); + g_free(s); + + return bootpath; +} + /* * This function returns null terminated string that consist of new line * separated device paths. @@ -218,36 +251,10 @@ char *get_boot_devices_list(size_t *size) bool ignore_suffixes = mc->ignore_boot_device_suffixes; QTAILQ_FOREACH(i, &fw_boot_order, link) { - char *devpath = NULL, *suffix = NULL; char *bootpath; - char *d; size_t len; - if (i->dev) { - devpath = qdev_get_fw_dev_path(i->dev); - assert(devpath); - } - - if (!ignore_suffixes) { - if (i->dev) { - d = qdev_get_own_fw_dev_path_from_handler(i->dev->parent_bus, - i->dev); - if (d) { - assert(!i->suffix); - suffix = d; - } else { - suffix = g_strdup(i->suffix); - } - } else { - suffix = g_strdup(i->suffix); - } - } - - bootpath = g_strdup_printf("%s%s", - devpath ? devpath : "", - suffix ? suffix : ""); - g_free(devpath); - g_free(suffix); + bootpath = get_boot_device_path(i->dev, ignore_suffixes, i->suffix); if (total) { list[total-1] = '\n'; -- 2.13.3 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values 2019-06-12 11:59 [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface Sam Eiderman ` (5 preceding siblings ...) 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 6/8] bootdevice: Refactor get_boot_devices_list Sam Eiderman @ 2019-06-12 11:59 ` Sam Eiderman 2019-06-17 7:20 ` Gerd Hoffmann 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 8/8] hd-geo-test: Add tests for lchs override Sam Eiderman ` (3 subsequent siblings) 10 siblings, 1 reply; 28+ messages in thread From: Sam Eiderman @ 2019-06-12 11:59 UTC (permalink / raw) To: kwolf, qemu-block, qemu-devel, mreitz, seabios, kraxel, kevin Cc: liran.alon, shmuel.eiderman, karl.heubaum, arbel.moshe Using fw_cfg, supply logical CHS values directly from QEMU to the BIOS. 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 report - SeaBIOS, for large enough disks - will use LBA translation, which will report 63 SPT instead. In addition we cannot force SeaBIOS to rely on physical geometries at all. A virtio-blk-pci virtual disk with 255 phyiscal heads cannot report more than 16 physical heads when moved to an IDE controller, since the ATA spec allows a maximum of 16 heads - this is an artifact of virtualization. By supplying the logical geometries directly we are able to support such "exotic" disks. We serialize this information in a similar way to the "bootorder" interface. The fw_cfg entry is "bootdevices" and it serializes a struct. At the moment the struct holds the values of logical CHS values but it can be expanded easily due to the extendable ABI implemented. (In the future, we can pass the bootindex through "bootdevices" instead "bootorder" - unifying all bootdevice information in one fw_cfg value) The PV interface through fw_cfg could have also been implemented using device specific keys, e.g.: "/etc/bootdevice/%s/logical_geometry" where %s is the device name QEMU produces - but this implementation would require much more code refactoring, both in QEMU and SeaBIOS, so the current implementation was chosen. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> --- bootdevice.c | 42 ++++++++++++++++++++++++++++++++++++++++++ hw/nvram/fw_cfg.c | 14 +++++++++++--- include/sysemu/sysemu.h | 1 + 3 files changed, 54 insertions(+), 3 deletions(-) diff --git a/bootdevice.c b/bootdevice.c index 2b12fb85a4..84c2a83f25 100644 --- a/bootdevice.c +++ b/bootdevice.c @@ -405,3 +405,45 @@ void del_boot_device_lchs(DeviceState *dev, const char *suffix) } } } + +typedef struct QEMU_PACKED BootDeviceEntrySerialized { + /* Do not change field order - add new fields below */ + uint32_t lcyls; + uint32_t lheads; + uint32_t lsecs; +} BootDeviceEntrySerialized; + +/* Serialized as: struct size (4) + (device name\0 + device struct) x devices */ +char *get_boot_devices_info(size_t *size) +{ + FWLCHSEntry *i; + BootDeviceEntrySerialized s; + size_t total = 0; + char *list = NULL; + + list = g_malloc0(sizeof(uint32_t)); + *((uint32_t *)list) = (uint32_t)sizeof(s); + total = sizeof(uint32_t); + + QTAILQ_FOREACH(i, &fw_lchs, link) { + char *bootpath; + size_t len; + + bootpath = get_boot_device_path(i->dev, false, i->suffix); + s.lcyls = i->lcyls; + s.lheads = i->lheads; + s.lsecs = i->lsecs; + + len = strlen(bootpath) + 1; + list = g_realloc(list, total + len + sizeof(s)); + memcpy(&list[total], bootpath, len); + memcpy(&list[total + len], &s, sizeof(s)); + total += len + sizeof(s); + + g_free(bootpath); + } + + *size = total; + + return list; +} diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c index 9f7b7789bc..008b21542f 100644 --- a/hw/nvram/fw_cfg.c +++ b/hw/nvram/fw_cfg.c @@ -916,13 +916,21 @@ void *fw_cfg_modify_file(FWCfgState *s, const char *filename, static void fw_cfg_machine_reset(void *opaque) { + MachineClass *mc = MACHINE_GET_CLASS(qdev_get_machine()); + FWCfgState *s = opaque; void *ptr; size_t len; - FWCfgState *s = opaque; - char *bootindex = get_boot_devices_list(&len); + char *buf; - ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t *)bootindex, len); + buf = get_boot_devices_list(&len); + ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t *)buf, len); g_free(ptr); + + if (!mc->legacy_fw_cfg_order) { + buf = get_boot_devices_info(&len); + ptr = fw_cfg_modify_file(s, "bootdevices", (uint8_t *)buf, len); + g_free(ptr); + } } static void fw_cfg_machine_ready(struct Notifier *n, void *data) diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h index 173dfbb539..f0552006f4 100644 --- a/include/sysemu/sysemu.h +++ b/include/sysemu/sysemu.h @@ -174,6 +174,7 @@ void validate_bootdevices(const char *devices, Error **errp); void add_boot_device_lchs(DeviceState *dev, const char *suffix, uint32_t lcyls, uint32_t lheads, uint32_t lsecs); void del_boot_device_lchs(DeviceState *dev, const char *suffix); +char *get_boot_devices_info(size_t *size); /* handler to set the boot_device order for a specific type of MachineClass */ typedef void QEMUBootSetHandler(void *opaque, const char *boot_order, -- 2.13.3 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values Sam Eiderman @ 2019-06-17 7:20 ` Gerd Hoffmann 2019-06-17 7:36 ` Sam Eiderman 0 siblings, 1 reply; 28+ messages in thread From: Gerd Hoffmann @ 2019-06-17 7:20 UTC (permalink / raw) To: Sam Eiderman Cc: kwolf, qemu-block, arbel.moshe, seabios, qemu-devel, mreitz, kevin, liran.alon, karl.heubaum Hi, > We serialize this information in a similar way to the "bootorder" > interface. > The fw_cfg entry is "bootdevices" and it serializes a struct. Why "bootdevices"? I'd suggest to use "geometry" or "lchs" instead. > At the moment the struct holds the values of logical CHS values but it > can be expanded easily due to the extendable ABI implemented. > > (In the future, we can pass the bootindex through "bootdevices" instead > "bootorder" - unifying all bootdevice information in one fw_cfg value) I don't think deprecating bootorder is useful. Nobody cares about the disk geometry, except some legacy x86 bios guests. So seabios will be the only firmware using this new interface. Switching all firmware to a new fw_cfg file is pointless churn. Why make this extendable? What possible extensions do you have in mind? Also note that with a possible extension you might end up in a situation where you have info A for device 1 and info B for device 2 and info A+B for device 3 while with your current patch there is no way to signal whenever info A or B is available for a given device. > +/* Serialized as: struct size (4) + (device name\0 + device struct) x devices */ > +char *get_boot_devices_info(size_t *size) > +{ > + FWLCHSEntry *i; > + BootDeviceEntrySerialized s; > + size_t total = 0; > + char *list = NULL; if (QTAILQ_EMPTY(&fw_lchs)) { return NULL; } > + if (!mc->legacy_fw_cfg_order) { ^^^^^^^^^^^^^^^^^^^ Hmm? cheers, Gerd ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values 2019-06-17 7:20 ` Gerd Hoffmann @ 2019-06-17 7:36 ` Sam Eiderman 2019-06-17 8:38 ` Gerd Hoffmann 2019-06-17 14:48 ` Kevin O'Connor 0 siblings, 2 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-17 7:36 UTC (permalink / raw) To: Gerd Hoffmann Cc: kwolf, qemu-block, arbel.moshe, seabios, qemu-devel, mreitz, kevin, liran.alon, karl.heubaum > On 17 Jun 2019, at 10:20, Gerd Hoffmann <kraxel@redhat.com> wrote: > > Hi, > >> We serialize this information in a similar way to the "bootorder" >> interface. >> The fw_cfg entry is "bootdevices" and it serializes a struct. > > Why "bootdevices"? I'd suggest to use "geometry" or "lchs" instead. True, if we don’t think an extension will be required in the future we might as well call it “lchs" or "bios-geometry”. > >> At the moment the struct holds the values of logical CHS values but it >> can be expanded easily due to the extendable ABI implemented. >> >> (In the future, we can pass the bootindex through "bootdevices" instead >> "bootorder" - unifying all bootdevice information in one fw_cfg value) > > I don't think deprecating bootorder is useful. Nobody cares about the > disk geometry, except some legacy x86 bios guests. So seabios will be > the only firmware using this new interface. Switching all firmware to a > new fw_cfg file is pointless churn. > > Why make this extendable? What possible extensions do you have in mind? I’m not sure about this but if “bootorder” was written in the first place using such an extension this could have been useful. I don’t have anything specific in mind. I don’t think deprecating bootorder is useful either, just mentioned that it will be possible if we would like to unify all disk values someday. > > Also note that with a possible extension you might end up in a situation > where you have info A for device 1 and info B for device 2 and info A+B > for device 3 while with your current patch there is no way to signal > whenever info A or B is available for a given device. Well for lchs (A) a non-existing value is 0, 0, 0 (uint32). So at the moment we’re good. We can signal other values with other magic numbers (such as -1 for bootorder) or prefix the value with an additional boolean value “is signaled”. > >> +/* Serialized as: struct size (4) + (device name\0 + device struct) x devices */ >> +char *get_boot_devices_info(size_t *size) >> +{ >> + FWLCHSEntry *i; >> + BootDeviceEntrySerialized s; >> + size_t total = 0; >> + char *list = NULL; > > if (QTAILQ_EMPTY(&fw_lchs)) { > return NULL; > } > >> + if (!mc->legacy_fw_cfg_order) { > ^^^^^^^^^^^^^^^^^^^ > Hmm? Only making this available in non-legacy mode. Qemu complains in get_fw_cfg_order() (fw_cfg.c): warn_report("Unknown firmware file in legacy mode: %s", name); Detected during qtests. So overall, WDYT? Keep it extendible for a low price of ABI + “bootdevices” name. Or go strict and rename to “bios-geometries”? (The ABI will not change too much anyway, the struct_size will disappear and sizeof(12) struct of LCHS will be assumed) Sam > > cheers, > Gerd > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values 2019-06-17 7:36 ` Sam Eiderman @ 2019-06-17 8:38 ` Gerd Hoffmann 2019-06-17 10:08 ` Sam Eiderman 2019-06-17 14:48 ` Kevin O'Connor 1 sibling, 1 reply; 28+ messages in thread From: Gerd Hoffmann @ 2019-06-17 8:38 UTC (permalink / raw) To: Sam Eiderman Cc: kwolf, qemu-block, arbel.moshe, seabios, qemu-devel, mreitz, kevin, liran.alon, karl.heubaum Hi, > Keep it extendible for a low price of ABI + “bootdevices” name. > Or go strict and rename to “bios-geometries”? The name should reflect what is in there, so "bios-geometries" looks better to me. I'd also keep it strict, unless we have at least a vague idea what might be a useful future extension. I don't have any. cheers, Gerd ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values 2019-06-17 8:38 ` Gerd Hoffmann @ 2019-06-17 10:08 ` Sam Eiderman 0 siblings, 0 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-17 10:08 UTC (permalink / raw) To: Gerd Hoffmann Cc: kwolf, qemu-block, arbel.moshe, seabios, qemu-devel, mreitz, kevin, liran.alon, karl.heubaum Ok, I’ll resubmit this patch series in v3, as well as v2 for SeaBIOS soon enough. * Change “bootdevices” to “bios-geometry”, and remove the struct size * Add cpu_to_le32 fix as Laszlo suggested or big endian hosts * Fix last qtest commit - automatic docker tester for some reason does not have qemu-img set Sam > On 17 Jun 2019, at 11:38, Gerd Hoffmann <kraxel@redhat.com> wrote: > > Hi, > >> Keep it extendible for a low price of ABI + “bootdevices” name. >> Or go strict and rename to “bios-geometries”? > > The name should reflect what is in there, so "bios-geometries" looks > better to me. I'd also keep it strict, unless we have at least a vague > idea what might be a useful future extension. I don't have any. > > cheers, > Gerd > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values 2019-06-17 7:36 ` Sam Eiderman 2019-06-17 8:38 ` Gerd Hoffmann @ 2019-06-17 14:48 ` Kevin O'Connor 2019-06-17 15:13 ` Sam Eiderman 1 sibling, 1 reply; 28+ messages in thread From: Kevin O'Connor @ 2019-06-17 14:48 UTC (permalink / raw) To: Sam Eiderman Cc: kwolf, qemu-block, arbel.moshe, seabios, qemu-devel, mreitz, liran.alon, Gerd Hoffmann, karl.heubaum On Mon, Jun 17, 2019 at 10:36:54AM +0300, Sam Eiderman wrote: > So overall, WDYT? > Keep it extendible for a low price of ABI + “bootdevices” name. > Or go strict and rename to “bios-geometries”? If we add another qemu to firmware interface I think the interface should be documented. I also think that a mix of an ascii and binary interface is going to be difficult to describe and document. I'd prefer a pure ascii interface - for example a newline separated list of four space separted fields: <device name> <cylinders> <heads> <spt> -Kevin ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values 2019-06-17 14:48 ` Kevin O'Connor @ 2019-06-17 15:13 ` Sam Eiderman 0 siblings, 0 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-17 15:13 UTC (permalink / raw) To: Kevin O'Connor Cc: kwolf, qemu-block, arbel.moshe, seabios, qemu-devel, mreitz, liran.alon, Gerd Hoffmann, karl.heubaum > On 17 Jun 2019, at 17:48, Kevin O'Connor <kevin@koconnor.net> wrote: > > On Mon, Jun 17, 2019 at 10:36:54AM +0300, Sam Eiderman wrote: >> So overall, WDYT? >> Keep it extendible for a low price of ABI + “bootdevices” name. >> Or go strict and rename to “bios-geometries”? > > If we add another qemu to firmware interface I think the interface > should be documented. I also think that a mix of an ascii and binary > interface is going to be difficult to describe and document. I'd > prefer a pure ascii interface - for example a newline separated list > of four space separted fields: <device name> <cylinders> <heads> <spt> We can go pure ascii. I meanwhile sent a v3 QEMU and v2 SeaBIOS patches for more comments. Sam > > -Kevin ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Qemu-devel] [QEMU] [PATCH v2 8/8] hd-geo-test: Add tests for lchs override 2019-06-12 11:59 [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface Sam Eiderman ` (6 preceding siblings ...) 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values Sam Eiderman @ 2019-06-12 11:59 ` Sam Eiderman 2019-06-12 12:33 ` [Qemu-devel] [SeaBIOS] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface no-reply ` (2 subsequent siblings) 10 siblings, 0 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-12 11:59 UTC (permalink / raw) To: kwolf, qemu-block, qemu-devel, mreitz, seabios, kraxel, kevin Cc: liran.alon, shmuel.eiderman, karl.heubaum, arbel.moshe Add QTest tests to check the logical geometry override option. The tests in hd-geo-test are out of date - they only test IDE and do not test interesting MBRs. I added a few helper functions which will make adding more tests easier. QTest's fw_cfg helper functions support only legacy fw_cfg, so I had to read the new fw_cfg layout on my own. Creating qcow2 disks with specific size and MBR layout is currently unused - we only use a default empty MBR. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> --- tests/Makefile.include | 2 +- tests/hd-geo-test.c | 565 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 566 insertions(+), 1 deletion(-) diff --git a/tests/Makefile.include b/tests/Makefile.include index 46a36c2c95..55ea165ed4 100644 --- a/tests/Makefile.include +++ b/tests/Makefile.include @@ -765,7 +765,7 @@ tests/ide-test$(EXESUF): tests/ide-test.o $(libqos-pc-obj-y) tests/ahci-test$(EXESUF): tests/ahci-test.o $(libqos-pc-obj-y) qemu-img$(EXESUF) tests/ipmi-kcs-test$(EXESUF): tests/ipmi-kcs-test.o tests/ipmi-bt-test$(EXESUF): tests/ipmi-bt-test.o -tests/hd-geo-test$(EXESUF): tests/hd-geo-test.o +tests/hd-geo-test$(EXESUF): tests/hd-geo-test.o $(libqos-obj-y) tests/boot-order-test$(EXESUF): tests/boot-order-test.o $(libqos-obj-y) tests/boot-serial-test$(EXESUF): tests/boot-serial-test.o $(libqos-obj-y) tests/bios-tables-test$(EXESUF): tests/bios-tables-test.o \ diff --git a/tests/hd-geo-test.c b/tests/hd-geo-test.c index 62eb624726..08eafeb81a 100644 --- a/tests/hd-geo-test.c +++ b/tests/hd-geo-test.c @@ -17,7 +17,11 @@ #include "qemu/osdep.h" #include "qemu-common.h" +#include "qemu/bswap.h" +#include "qapi/qmp/qlist.h" #include "libqtest.h" +#include "libqos/fw_cfg.h" +#include "standard-headers/linux/qemu_fw_cfg.h" #define ARGV_SIZE 256 @@ -388,6 +392,557 @@ static void test_ide_drive_cd_0(void) qtest_quit(qts); } +typedef struct { + bool active; + uint32_t head; + uint32_t sector; + uint32_t cyl; + uint32_t end_head; + uint32_t end_sector; + uint32_t end_cyl; + uint32_t start_sect; + uint32_t nr_sects; +} MBRpartitions[4]; + +static MBRpartitions empty_mbr = { {false, 0, 0, 0, 0, 0, 0, 0, 0}, + {false, 0, 0, 0, 0, 0, 0, 0, 0}, + {false, 0, 0, 0, 0, 0, 0, 0, 0}, + {false, 0, 0, 0, 0, 0, 0, 0, 0} }; + +static char *create_qcow2_with_mbr(MBRpartitions mbr, uint64_t sectors) +{ + const char *template = "/tmp/qtest.XXXXXX"; + char *raw_path = strdup(template); + char *qcow2_path = strdup(template); + char cmd[100 + 2 * PATH_MAX]; + uint8_t buf[512]; + int i, ret, fd, offset; + uint64_t qcow2_size = sectors * 512; + uint8_t status, parttype, head, sector, cyl; + + offset = 0xbe; + + for (i = 0; i < 4; i++) { + status = mbr[i].active ? 0x80 : 0x00; + g_assert(mbr[i].head < 256); + g_assert(mbr[i].sector < 64); + g_assert(mbr[i].cyl < 1024); + head = mbr[i].head; + sector = mbr[i].sector + ((mbr[i].cyl & 0x300) >> 2); + cyl = mbr[i].cyl & 0xff; + + buf[offset + 0x0] = status; + buf[offset + 0x1] = head; + buf[offset + 0x2] = sector; + buf[offset + 0x3] = cyl; + + parttype = 0; + g_assert(mbr[i].end_head < 256); + g_assert(mbr[i].end_sector < 64); + g_assert(mbr[i].end_cyl < 1024); + head = mbr[i].end_head; + sector = mbr[i].end_sector + ((mbr[i].end_cyl & 0x300) >> 2); + cyl = mbr[i].end_cyl & 0xff; + + buf[offset + 0x4] = parttype; + buf[offset + 0x5] = head; + buf[offset + 0x6] = sector; + buf[offset + 0x7] = cyl; + + (*(uint32_t *)&buf[offset + 0x8]) = cpu_to_le32(mbr[i].start_sect); + (*(uint32_t *)&buf[offset + 0xc]) = cpu_to_le32(mbr[i].nr_sects); + + offset += 0x10; + } + + fd = mkstemp(raw_path); + g_assert(fd); + close(fd); + + fd = open(raw_path, O_WRONLY); + g_assert(fd >= 0); + ret = write(fd, buf, sizeof(buf)); + g_assert(ret == sizeof(buf)); + close(fd); + + fd = mkstemp(qcow2_path); + g_assert(fd); + close(fd); + + ret = snprintf(cmd, sizeof(cmd), + "$QTEST_QEMU_IMG convert -f raw -O qcow2 %s %s > /dev/null", + raw_path, qcow2_path); + g_assert((0 < ret) && (ret <= sizeof(cmd))); + ret = system(cmd); + g_assert(ret == 0); + + ret = snprintf(cmd, sizeof(cmd), + "$QTEST_QEMU_IMG resize %s %" PRIu64 " > /dev/null", + qcow2_path, qcow2_size); + g_assert((0 < ret) && (ret <= sizeof(cmd))); + ret = system(cmd); + g_assert(ret == 0); + + unlink(raw_path); + free(raw_path); + + return qcow2_path; +} + +struct QemuCfgFile { + uint32_t size; /* file size */ + uint16_t select; /* write this to 0x510 to read it */ + uint16_t reserved; + char name[56]; +}; + +static uint16_t find_fw_cfg_file(QFWCFG *fw_cfg, + const char *filename) +{ + struct QemuCfgFile qfile; + uint32_t count, e; + uint16_t select; + + count = qfw_cfg_get_u32(fw_cfg, FW_CFG_FILE_DIR); + count = be32_to_cpu(count); + for (select = 0, e = 0; e < count; e++) { + qfw_cfg_read_data(fw_cfg, &qfile, sizeof(qfile)); + if (!strcmp(filename, qfile.name)) { + select = be16_to_cpu(qfile.select); + } + } + + return select; +} + +static void read_fw_cfg_file(QFWCFG *fw_cfg, + const char *filename, + void *data, + size_t len) +{ + uint16_t select = find_fw_cfg_file(fw_cfg, filename); + + g_assert(select); + + qfw_cfg_get(fw_cfg, select, data, len); +} + +#define BOOTDEVICES_MAX_SIZE 10000 + +typedef struct { + uint32_t c; + uint32_t h; + uint32_t s; +} CHS; + +typedef struct { + const char *dev_path; + CHS chs; +} CHSResult; + +static void read_bootdevices(QFWCFG *fw_cfg, CHSResult expected[]) +{ + uint32_t info_size; + char *buf = g_malloc0(BOOTDEVICES_MAX_SIZE); + void *cur; + char *name; + CHS *chs; + GList *results = NULL, *cur_result; + CHSResult *r; + int i; + bool found; + + read_fw_cfg_file(fw_cfg, "bootdevices", buf, BOOTDEVICES_MAX_SIZE); + + cur = buf; + + info_size = *((uint32_t *)cur); + + g_assert(info_size >= sizeof(*chs)); + + cur += 4; + + while (strlen(cur)) { + name = cur; + chs = cur + strlen(cur) + 1; + + r = g_malloc0(sizeof(*r)); + r->dev_path = name; + r->chs = *chs; + + results = g_list_prepend(results, r); + + cur += strlen(cur) + 1 + info_size; + } + + i = 0; + + while (expected[i].dev_path) { + found = false; + cur_result = results; + while (cur_result) { + r = cur_result->data; + if (!strcmp(r->dev_path, expected[i].dev_path) && + !memcmp(&(r->chs), &(expected[i].chs), sizeof(r->chs))) { + found = true; + break; + } + cur_result = g_list_next(cur_result); + } + g_assert(found); + g_free(cur_result->data); + results = g_list_delete_link(results, cur_result); + i++; + } + + g_assert(results == NULL); + + g_free(buf); +} + +#define MAX_DRIVES 30 + +typedef struct { + char **argv; + int argc; + char **drives; + int n_drives; + int n_scsi_disks; + int n_scsi_controllers; + int n_virtio_disks; +} TestArgs; + +static TestArgs *create_args(void) +{ + TestArgs *args = g_malloc0(sizeof(*args)); + args->argv = g_new0(char *, ARGV_SIZE); + args->argc = append_arg(args->argc, args->argv, + ARGV_SIZE, g_strdup("-nodefaults")); + args->drives = g_new0(char *, MAX_DRIVES); + return args; +} + +static void add_drive_with_mbr(TestArgs *args, + MBRpartitions mbr, uint64_t sectors) +{ + char *img_file_name; + char part[300]; + int ret; + + g_assert(args->n_drives < MAX_DRIVES); + + img_file_name = create_qcow2_with_mbr(mbr, sectors); + + args->drives[args->n_drives] = img_file_name; + ret = snprintf(part, sizeof(part), + "-drive file=%s,if=none,format=qcow2,id=disk%d", + img_file_name, args->n_drives); + g_assert((0 < ret) && (ret <= sizeof(part))); + args->argc = append_arg(args->argc, args->argv, ARGV_SIZE, g_strdup(part)); + args->n_drives++; +} + +static void add_ide_disk(TestArgs *args, + int drive_idx, int bus, int unit, int c, int h, int s) +{ + char part[300]; + int ret; + + ret = snprintf(part, sizeof(part), + "-device ide-hd,drive=disk%d,bus=ide.%d,unit=%d," + "lcyls=%d,lheads=%d,lsecs=%d", + drive_idx, bus, unit, c, h, s); + g_assert((0 < ret) && (ret <= sizeof(part))); + args->argc = append_arg(args->argc, args->argv, ARGV_SIZE, g_strdup(part)); +} + +static void add_scsi_controller(TestArgs *args, + const char *type, + const char *bus, + int addr) +{ + char part[300]; + int ret; + + ret = snprintf(part, sizeof(part), + "-device %s,id=scsi%d,bus=%s,addr=%d", + type, args->n_scsi_controllers, bus, addr); + g_assert((0 < ret) && (ret <= sizeof(part))); + args->argc = append_arg(args->argc, args->argv, ARGV_SIZE, g_strdup(part)); + args->n_scsi_controllers++; +} + +static void add_scsi_disk(TestArgs *args, + int drive_idx, int bus, + int channel, int scsi_id, int lun, + int c, int h, int s) +{ + char part[300]; + int ret; + + ret = snprintf(part, sizeof(part), + "-device scsi-hd,id=scsi-disk%d,drive=disk%d," + "bus=scsi%d.0," + "channel=%d,scsi-id=%d,lun=%d," + "lcyls=%d,lheads=%d,lsecs=%d", + args->n_scsi_disks, drive_idx, bus, channel, scsi_id, lun, + c, h, s); + g_assert((0 < ret) && (ret <= sizeof(part))); + args->argc = append_arg(args->argc, args->argv, ARGV_SIZE, g_strdup(part)); + args->n_scsi_disks++; +} + +static void add_virtio_disk(TestArgs *args, + int drive_idx, const char *bus, int addr, + int c, int h, int s) +{ + char part[300]; + int ret; + + ret = snprintf(part, sizeof(part), + "-device virtio-blk-pci,id=virtio-disk%d," + "drive=disk%d,bus=%s,addr=%d," + "lcyls=%d,lheads=%d,lsecs=%d", + args->n_virtio_disks, drive_idx, bus, addr, c, h, s); + g_assert((0 < ret) && (ret <= sizeof(part))); + args->argc = append_arg(args->argc, args->argv, ARGV_SIZE, g_strdup(part)); + args->n_virtio_disks++; +} + +static void test_override(TestArgs *args, CHSResult expected[]) +{ + char *joined_args; + QFWCFG *fw_cfg; + int i; + + joined_args = g_strjoinv(" ", args->argv); + + qtest_start(joined_args); + fw_cfg = pc_fw_cfg_init(global_qtest); + + read_bootdevices(fw_cfg, expected); + + g_free(joined_args); + qtest_end(); + + g_free(fw_cfg); + + for (i = 0; i < args->n_drives; i++) { + unlink(args->drives[i]); + free(args->drives[i]); + } + g_free(args->drives); + g_strfreev(args->argv); + g_free(args); +} + +static void test_override_ide(void) +{ + TestArgs *args = create_args(); + CHSResult expected[] = { + {"/pci@i0cf8/ide@1,1/drive@0/disk@0", {10000, 120, 30} }, + {"/pci@i0cf8/ide@1,1/drive@0/disk@1", {9000, 120, 30} }, + {"/pci@i0cf8/ide@1,1/drive@1/disk@0", {0, 1, 1} }, + {"/pci@i0cf8/ide@1,1/drive@1/disk@1", {1, 0, 0} }, + {NULL, {0, 0, 0} } + }; + add_drive_with_mbr(args, empty_mbr, 1); + add_drive_with_mbr(args, empty_mbr, 1); + add_drive_with_mbr(args, empty_mbr, 1); + add_drive_with_mbr(args, empty_mbr, 1); + add_ide_disk(args, 0, 0, 0, 10000, 120, 30); + add_ide_disk(args, 1, 0, 1, 9000, 120, 30); + add_ide_disk(args, 2, 1, 0, 0, 1, 1); + add_ide_disk(args, 3, 1, 1, 1, 0, 0); + test_override(args, expected); +} + +static void test_override_scsi(void) +{ + TestArgs *args = create_args(); + CHSResult expected[] = { + {"/pci@i0cf8/scsi@3/channel@0/disk@0,0", {10000, 120, 30} }, + {"/pci@i0cf8/scsi@3/channel@0/disk@1,0", {9000, 120, 30} }, + {"/pci@i0cf8/scsi@3/channel@0/disk@2,0", {1, 0, 0} }, + {"/pci@i0cf8/scsi@3/channel@0/disk@3,0", {0, 1, 0} }, + {NULL, {0, 0, 0} } + }; + add_drive_with_mbr(args, empty_mbr, 1); + add_drive_with_mbr(args, empty_mbr, 1); + add_drive_with_mbr(args, empty_mbr, 1); + add_drive_with_mbr(args, empty_mbr, 1); + add_scsi_controller(args, "lsi53c895a", "pci.0", 3); + add_scsi_disk(args, 0, 0, 0, 0, 0, 10000, 120, 30); + add_scsi_disk(args, 1, 0, 0, 1, 0, 9000, 120, 30); + add_scsi_disk(args, 2, 0, 0, 2, 0, 1, 0, 0); + add_scsi_disk(args, 3, 0, 0, 3, 0, 0, 1, 0); + test_override(args, expected); +} + +static void test_override_scsi_2_controllers(void) +{ + TestArgs *args = create_args(); + CHSResult expected[] = { + {"/pci@i0cf8/scsi@3/channel@0/disk@0,0", {10000, 120, 30} }, + {"/pci@i0cf8/scsi@3/channel@0/disk@1,0", {9000, 120, 30} }, + {"/pci@i0cf8/scsi@4/channel@0/disk@0,1", {1, 0, 0} }, + {"/pci@i0cf8/scsi@4/channel@0/disk@1,2", {0, 1, 0} }, + {NULL, {0, 0, 0} } + }; + add_drive_with_mbr(args, empty_mbr, 1); + add_drive_with_mbr(args, empty_mbr, 1); + add_drive_with_mbr(args, empty_mbr, 1); + add_drive_with_mbr(args, empty_mbr, 1); + add_scsi_controller(args, "lsi53c895a", "pci.0", 3); + add_scsi_controller(args, "virtio-scsi-pci", "pci.0", 4); + add_scsi_disk(args, 0, 0, 0, 0, 0, 10000, 120, 30); + add_scsi_disk(args, 1, 0, 0, 1, 0, 9000, 120, 30); + add_scsi_disk(args, 2, 1, 0, 0, 1, 1, 0, 0); + add_scsi_disk(args, 3, 1, 0, 1, 2, 0, 1, 0); + test_override(args, expected); +} + +static void test_override_virtio_blk(void) +{ + TestArgs *args = create_args(); + CHSResult expected[] = { + {"/pci@i0cf8/scsi@3/disk@0,0", {10000, 120, 30} }, + {"/pci@i0cf8/scsi@4/disk@0,0", {9000, 120, 30} }, + {NULL, {0, 0, 0} } + }; + add_drive_with_mbr(args, empty_mbr, 1); + add_drive_with_mbr(args, empty_mbr, 1); + add_virtio_disk(args, 0, "pci.0", 3, 10000, 120, 30); + add_virtio_disk(args, 1, "pci.0", 4, 9000, 120, 30); + test_override(args, expected); +} + +static void test_override_zero_chs(void) +{ + TestArgs *args = create_args(); + CHSResult expected[] = { + {NULL, {0, 0, 0} } + }; + add_drive_with_mbr(args, empty_mbr, 1); + add_ide_disk(args, 0, 1, 1, 0, 0, 0); + test_override(args, expected); +} + +static void test_override_scsi_hot_unplug(void) +{ + char *joined_args; + QFWCFG *fw_cfg; + QDict *response; + int i; + TestArgs *args = create_args(); + CHSResult expected[] = { + {"/pci@i0cf8/scsi@2/channel@0/disk@0,0", {10000, 120, 30} }, + {"/pci@i0cf8/scsi@2/channel@0/disk@1,0", {20, 20, 20} }, + {NULL, {0, 0, 0} } + }; + CHSResult expected2[] = { + {"/pci@i0cf8/scsi@2/channel@0/disk@1,0", {20, 20, 20} }, + {NULL, {0, 0, 0} } + }; + add_drive_with_mbr(args, empty_mbr, 1); + add_drive_with_mbr(args, empty_mbr, 1); + add_scsi_controller(args, "virtio-scsi-pci", "pci.0", 2); + add_scsi_disk(args, 0, 0, 0, 0, 0, 10000, 120, 30); + add_scsi_disk(args, 1, 0, 0, 1, 0, 20, 20, 20); + + joined_args = g_strjoinv(" ", args->argv); + + qtest_start(joined_args); + fw_cfg = pc_fw_cfg_init(global_qtest); + + read_bootdevices(fw_cfg, expected); + + /* unplug device an restart */ + response = qmp("{ 'execute': 'device_del'," + " 'arguments': {'id': 'scsi-disk0' }}"); + g_assert(response); + g_assert(!qdict_haskey(response, "error")); + qobject_unref(response); + response = qmp("{ 'execute': 'system_reset', 'arguments': { }}"); + g_assert(response); + g_assert(!qdict_haskey(response, "error")); + qobject_unref(response); + + qtest_qmp_eventwait(global_qtest, "RESET"); + + read_bootdevices(fw_cfg, expected2); + + g_free(joined_args); + qtest_end(); + + g_free(fw_cfg); + + for (i = 0; i < args->n_drives; i++) { + unlink(args->drives[i]); + free(args->drives[i]); + } + g_free(args->drives); + g_strfreev(args->argv); + g_free(args); +} + +static void test_override_virtio_hot_unplug(void) +{ + char *joined_args; + QFWCFG *fw_cfg; + QDict *response; + int i; + TestArgs *args = create_args(); + CHSResult expected[] = { + {"/pci@i0cf8/scsi@2/disk@0,0", {10000, 120, 30} }, + {"/pci@i0cf8/scsi@3/disk@0,0", {20, 20, 20} }, + {NULL, {0, 0, 0} } + }; + CHSResult expected2[] = { + {"/pci@i0cf8/scsi@3/disk@0,0", {20, 20, 20} }, + {NULL, {0, 0, 0} } + }; + add_drive_with_mbr(args, empty_mbr, 1); + add_drive_with_mbr(args, empty_mbr, 1); + add_virtio_disk(args, 0, "pci.0", 2, 10000, 120, 30); + add_virtio_disk(args, 1, "pci.0", 3, 20, 20, 20); + + joined_args = g_strjoinv(" ", args->argv); + + qtest_start(joined_args); + fw_cfg = pc_fw_cfg_init(global_qtest); + + read_bootdevices(fw_cfg, expected); + + /* unplug device an restart */ + response = qmp("{ 'execute': 'device_del'," + " 'arguments': {'id': 'virtio-disk0' }}"); + g_assert(response); + g_assert(!qdict_haskey(response, "error")); + qobject_unref(response); + response = qmp("{ 'execute': 'system_reset', 'arguments': { }}"); + g_assert(response); + g_assert(!qdict_haskey(response, "error")); + qobject_unref(response); + + qtest_qmp_eventwait(global_qtest, "RESET"); + + read_bootdevices(fw_cfg, expected2); + + g_free(joined_args); + qtest_end(); + + g_free(fw_cfg); + + for (i = 0; i < args->n_drives; i++) { + unlink(args->drives[i]); + free(args->drives[i]); + } + g_free(args->drives); + g_strfreev(args->argv); + g_free(args); +} + int main(int argc, char **argv) { Backend i; @@ -413,6 +968,16 @@ int main(int argc, char **argv) qtest_add_func("hd-geo/ide/device/mbr/chs", test_ide_device_mbr_chs); qtest_add_func("hd-geo/ide/device/user/chs", test_ide_device_user_chs); qtest_add_func("hd-geo/ide/device/user/chst", test_ide_device_user_chst); + qtest_add_func("hd-geo/override/ide", test_override_ide); + qtest_add_func("hd-geo/override/scsi", test_override_scsi); + qtest_add_func("hd-geo/override/scsi_2_controllers", + test_override_scsi_2_controllers); + qtest_add_func("hd-geo/override/virtio_blk", test_override_virtio_blk); + qtest_add_func("hd-geo/override/zero_chs", test_override_zero_chs); + qtest_add_func("hd-geo/override/scsi_hot_unplug", + test_override_scsi_hot_unplug); + qtest_add_func("hd-geo/override/virtio_hot_unplug", + test_override_virtio_hot_unplug); ret = g_test_run(); -- 2.13.3 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [SeaBIOS] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface 2019-06-12 11:59 [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface Sam Eiderman ` (7 preceding siblings ...) 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 8/8] hd-geo-test: Add tests for lchs override Sam Eiderman @ 2019-06-12 12:33 ` no-reply 2019-06-12 13:06 ` [Qemu-devel] " Gerd Hoffmann 2019-06-12 13:51 ` [Qemu-devel] [SeaBIOS] " no-reply 10 siblings, 0 replies; 28+ messages in thread From: no-reply @ 2019-06-12 12:33 UTC (permalink / raw) To: shmuel.eiderman Cc: kwolf, qemu-block, arbel.moshe, seabios, qemu-devel, mreitz, kevin, kraxel, karl.heubaum 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface 2019-06-12 11:59 [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface Sam Eiderman ` (8 preceding siblings ...) 2019-06-12 12:33 ` [Qemu-devel] [SeaBIOS] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface no-reply @ 2019-06-12 13:06 ` Gerd Hoffmann 2019-06-12 13:30 ` Sam Eiderman 2019-06-12 13:51 ` [Qemu-devel] [SeaBIOS] " no-reply 10 siblings, 1 reply; 28+ messages in thread From: Gerd Hoffmann @ 2019-06-12 13:06 UTC (permalink / raw) To: Sam Eiderman Cc: kwolf, qemu-block, arbel.moshe, seabios, qemu-devel, mreitz, kevin, liran.alon, karl.heubaum 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface 2019-06-12 13:06 ` [Qemu-devel] " Gerd Hoffmann @ 2019-06-12 13:30 ` Sam Eiderman 2019-06-12 19:18 ` Gerd Hoffmann 0 siblings, 1 reply; 28+ messages in thread From: Sam Eiderman @ 2019-06-12 13:30 UTC (permalink / raw) To: Gerd Hoffmann Cc: kwolf, qemu-block, arbel.moshe, seabios, QEMU, mreitz, kevin, liran.alon, karl.heubaum > 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface 2019-06-12 13:30 ` Sam Eiderman @ 2019-06-12 19:18 ` Gerd Hoffmann 2019-06-13 7:41 ` Sam Eiderman 0 siblings, 1 reply; 28+ messages in thread From: Gerd Hoffmann @ 2019-06-12 19:18 UTC (permalink / raw) To: Sam Eiderman Cc: kwolf, qemu-block, arbel.moshe, seabios, QEMU, mreitz, kevin, liran.alon, karl.heubaum 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface 2019-06-12 19:18 ` Gerd Hoffmann @ 2019-06-13 7:41 ` Sam Eiderman 2019-06-13 7:44 ` Sam Eiderman 2019-06-13 9:38 ` Gerd Hoffmann 0 siblings, 2 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-13 7:41 UTC (permalink / raw) To: Gerd Hoffmann Cc: kwolf, qemu-block, arbel.moshe, seabios, QEMU, mreitz, kevin, liran.alon, karl.heubaum > 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface 2019-06-13 7:41 ` Sam Eiderman @ 2019-06-13 7:44 ` Sam Eiderman 2019-06-13 9:38 ` Gerd Hoffmann 1 sibling, 0 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-13 7:44 UTC (permalink / raw) To: Gerd Hoffmann Cc: kwolf, qemu-block, arbel.moshe, seabios, QEMU, mreitz, kevin, liran.alon, karl.heubaum 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface 2019-06-13 7:41 ` Sam Eiderman 2019-06-13 7:44 ` Sam Eiderman @ 2019-06-13 9:38 ` Gerd Hoffmann 2019-06-13 11:45 ` Sam Eiderman 1 sibling, 1 reply; 28+ messages in thread From: Gerd Hoffmann @ 2019-06-13 9:38 UTC (permalink / raw) To: Sam Eiderman Cc: kwolf, qemu-block, arbel.moshe, seabios, QEMU, mreitz, kevin, liran.alon, karl.heubaum 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface 2019-06-13 9:38 ` Gerd Hoffmann @ 2019-06-13 11:45 ` Sam Eiderman 2019-06-14 4:43 ` Gerd Hoffmann 0 siblings, 1 reply; 28+ messages in thread From: Sam Eiderman @ 2019-06-13 11:45 UTC (permalink / raw) To: Gerd Hoffmann Cc: kwolf, qemu-block, arbel.moshe, seabios, QEMU, Max Reitz, Kevin O'Connor, liran.alon, Karl Heubaum > 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface 2019-06-13 11:45 ` Sam Eiderman @ 2019-06-14 4:43 ` Gerd Hoffmann 2019-06-14 9:37 ` Sam Eiderman 0 siblings, 1 reply; 28+ messages in thread From: Gerd Hoffmann @ 2019-06-14 4:43 UTC (permalink / raw) To: Sam Eiderman Cc: kwolf, qemu-block, arbel.moshe, seabios, QEMU, Max Reitz, Kevin O'Connor, liran.alon, Karl Heubaum 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface 2019-06-14 4:43 ` Gerd Hoffmann @ 2019-06-14 9:37 ` Sam Eiderman 2019-06-17 6:50 ` Gerd Hoffmann 0 siblings, 1 reply; 28+ messages in thread From: Sam Eiderman @ 2019-06-14 9:37 UTC (permalink / raw) To: Gerd Hoffmann Cc: kwolf, qemu-block, arbel.moshe, seabios, QEMU, Max Reitz, Kevin O'Connor, liran.alon, Karl Heubaum > 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface 2019-06-14 9:37 ` Sam Eiderman @ 2019-06-17 6:50 ` Gerd Hoffmann 2019-06-17 7:59 ` Sam Eiderman 0 siblings, 1 reply; 28+ messages in thread From: Gerd Hoffmann @ 2019-06-17 6:50 UTC (permalink / raw) To: Sam Eiderman Cc: kwolf, qemu-block, arbel.moshe, seabios, QEMU, Max Reitz, Kevin O'Connor, liran.alon, Karl Heubaum 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface 2019-06-17 6:50 ` Gerd Hoffmann @ 2019-06-17 7:59 ` Sam Eiderman 0 siblings, 0 replies; 28+ messages in thread From: Sam Eiderman @ 2019-06-17 7:59 UTC (permalink / raw) To: Gerd Hoffmann Cc: kwolf, qemu-block, Arbel Moshe, seabios, QEMU, Max Reitz, Kevin O'Connor, liran.alon, Karl Heubaum > 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [SeaBIOS] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface 2019-06-12 11:59 [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface Sam Eiderman ` (9 preceding siblings ...) 2019-06-12 13:06 ` [Qemu-devel] " Gerd Hoffmann @ 2019-06-12 13:51 ` no-reply 10 siblings, 0 replies; 28+ messages in thread From: no-reply @ 2019-06-12 13:51 UTC (permalink / raw) To: shmuel.eiderman Cc: kwolf, qemu-block, arbel.moshe, seabios, qemu-devel, mreitz, kevin, kraxel, karl.heubaum 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2019-06-17 16:39 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-12 11:59 [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 1/8] block: Refactor macros - fix tabbing Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 2/8] block: Support providing LCHS from user Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 3/8] bootdevice: Add interface to gather LCHS Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 4/8] scsi: Propagate unrealize() callback to scsi-hd Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 5/8] bootdevice: Gather LCHS from all relevant devices Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 6/8] bootdevice: Refactor get_boot_devices_list Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values Sam Eiderman 2019-06-17 7:20 ` Gerd Hoffmann 2019-06-17 7:36 ` Sam Eiderman 2019-06-17 8:38 ` Gerd Hoffmann 2019-06-17 10:08 ` Sam Eiderman 2019-06-17 14:48 ` Kevin O'Connor 2019-06-17 15:13 ` Sam Eiderman 2019-06-12 11:59 ` [Qemu-devel] [QEMU] [PATCH v2 8/8] hd-geo-test: Add tests for lchs override Sam Eiderman 2019-06-12 12:33 ` [Qemu-devel] [SeaBIOS] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface no-reply 2019-06-12 13:06 ` [Qemu-devel] " Gerd Hoffmann 2019-06-12 13:30 ` Sam Eiderman 2019-06-12 19:18 ` Gerd Hoffmann 2019-06-13 7:41 ` Sam Eiderman 2019-06-13 7:44 ` Sam Eiderman 2019-06-13 9:38 ` Gerd Hoffmann 2019-06-13 11:45 ` Sam Eiderman 2019-06-14 4:43 ` Gerd Hoffmann 2019-06-14 9:37 ` Sam Eiderman 2019-06-17 6:50 ` Gerd Hoffmann 2019-06-17 7:59 ` Sam Eiderman 2019-06-12 13:51 ` [Qemu-devel] [SeaBIOS] " no-reply
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.