[Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Sam Eiderman]

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

[Qemu-devel] [QEMU] [PATCH v2 1/8] block: Refactor macros - fix tabbing

[Sam Eiderman]

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

[Qemu-devel] [QEMU] [PATCH v2 2/8] block: Support providing LCHS from user

[Sam Eiderman]

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

[Qemu-devel] [QEMU] [PATCH v2 3/8] bootdevice: Add interface to gather LCHS

[Sam Eiderman]

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

[Qemu-devel] [QEMU] [PATCH v2 4/8] scsi: Propagate unrealize() callback to scsi-hd

[Sam Eiderman]

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

[Qemu-devel] [QEMU] [PATCH v2 5/8] bootdevice: Gather LCHS from all relevant devices

[Sam Eiderman]

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

[Qemu-devel] [QEMU] [PATCH v2 6/8] bootdevice: Refactor get_boot_devices_list

[Sam Eiderman]

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

[Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values

[Sam Eiderman]

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

[Qemu-devel] [QEMU] [PATCH v2 8/8] hd-geo-test: Add tests for lchs override

[Sam Eiderman]

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

Re: [Qemu-devel] [SeaBIOS] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[no-reply]

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

Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Gerd Hoffmann]

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

Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Sam Eiderman]

> 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
> 

Re: [Qemu-devel] [SeaBIOS] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[no-reply]

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

Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Gerd Hoffmann]

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

Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Sam Eiderman]

> 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

Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Sam Eiderman]

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

Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Gerd Hoffmann]

  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

Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Sam Eiderman]

> 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
> 

Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Gerd Hoffmann]

  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

Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Sam Eiderman]

> 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
> 

Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Gerd Hoffmann]

  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

Re: [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values

[Gerd Hoffmann]

  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

Re: [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values

[Sam Eiderman]

> 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
> 

Re: [Qemu-devel] [QEMU] [PATCH v2 0/8] Add Qemu to SeaBIOS LCHS interface

[Sam Eiderman]

> 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
> 

Re: [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values

[Gerd Hoffmann]

  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

Re: [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values

[Sam Eiderman]

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
> 

Re: [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values

[Kevin O'Connor]

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

Re: [Qemu-devel] [QEMU] [PATCH v2 7/8] bootdevice: FW_CFG interface for LCHS values

[Sam Eiderman]

> 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