[Qemu-devel] [PULL 0/3] s390x fixes for 2.7

[Qemu-devel] [PULL 0/3] s390x fixes for 2.7

[Cornelia Huck]

ck/qemu s390x-20160720
The following changes since commit 1ecfb24da987b862fd46a5b37292879952ea9e7d:

  Merge remote-tracking branch 'remotes/riku/tags/pull-linux-user-20160719-2' into staging (2016-07-20 11:32:12 +0100)

are available in the git repository at:

  git://github.com/cohuck/qemu tags/s390x-20160720

for you to fetch changes up to 2a79eb1a616a07b0e8c41430f03af254fefe219d:

  s390x/css: provide a dev_path for css devices (2016-07-20 15:47:25 +0200)

----------------------------------------------------------------
Fixes for s390x in the css area.

----------------------------------------------------------------

Cornelia Huck (1):
  s390x/css: provide a dev_path for css devices

Sascha Silbe (2):
  s390x/css: copy CCW format bit from ORB to SCSW
  s390x/css: sch_handle_start_func() handles resume, too

 hw/s390x/css-bridge.c         | 26 +++++++++++++++++++++++++-
 hw/s390x/css.c                |  5 +++++
 hw/s390x/s390-virtio-ccw.c    |  4 ++++
 include/hw/s390x/css-bridge.h |  7 +++++++
 4 files changed, 41 insertions(+), 1 deletion(-)

-- 
2.9.2

[Qemu-devel] [PULL 1/3] s390x/css: copy CCW format bit from ORB to SCSW

[Cornelia Huck]

From: Sascha Silbe <silbe@linux.vnet.ibm.com>

The CCW Format (F) flag of the Subchannel-Status Word (SCSW) indicates
the format of the CCWs "associated with an I/O operation", i.e. the
value of CCW-Format Control (F) bit of the Operation-Request Block
(ORB).

Copy the CCW format bit from the ORB to the SCSW so we correctly
indicate the format of the CCWs to the guest.

Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
---
 hw/s390x/css.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index aa61773..9e98f50 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -524,6 +524,7 @@ static void sch_handle_start_func(SubchDev *sch, ORB *orb)
             return;
         }
         sch->ccw_fmt_1 = !!(orb->ctrl0 & ORB_CTRL0_MASK_FMT);
+        s->flags |= (sch->ccw_fmt_1) ? SCSW_FLAGS_MASK_FMT : 0;
         sch->ccw_no_data_cnt = 0;
         suspend_allowed = !!(orb->ctrl0 & ORB_CTRL0_MASK_SPND);
     } else {
-- 
2.9.2

[Qemu-devel] [PULL 2/3] s390x/css: sch_handle_start_func() handles resume, too

[Cornelia Huck]

From: Sascha Silbe <silbe@linux.vnet.ibm.com>

It's not obvious from the code flow that sch_handle_start_func() gets
called for rsch. Add some comments explaining this.

Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
---
 hw/s390x/css.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 9e98f50..bb8e4be 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -511,6 +511,7 @@ static void sch_handle_start_func(SubchDev *sch, ORB *orb)
     path = 0x80;
 
     if (!(s->ctrl & SCSW_ACTL_SUSP)) {
+        /* Start Function triggered via ssch, i.e. we have an ORB */
         s->cstat = 0;
         s->dstat = 0;
         /* Look at the orb and try to execute the channel program. */
@@ -528,6 +529,8 @@ static void sch_handle_start_func(SubchDev *sch, ORB *orb)
         sch->ccw_no_data_cnt = 0;
         suspend_allowed = !!(orb->ctrl0 & ORB_CTRL0_MASK_SPND);
     } else {
+        /* Start Function resumed via rsch, i.e. we don't have an
+         * ORB */
         s->ctrl &= ~(SCSW_ACTL_SUSP | SCSW_ACTL_RESUME_PEND);
         /* The channel program had been suspended before. */
         suspend_allowed = true;
@@ -610,6 +613,7 @@ static void do_subchannel_work(SubchDev *sch, ORB *orb)
     } else if (s->ctrl & SCSW_FCTL_HALT_FUNC) {
         sch_handle_halt_func(sch);
     } else if (s->ctrl & SCSW_FCTL_START_FUNC) {
+        /* Triggered by both ssch and rsch. */
         sch_handle_start_func(sch, orb);
     } else {
         /* Cannot happen. */
-- 
2.9.2

[Qemu-devel] [PULL 3/3] s390x/css: provide a dev_path for css devices

[Cornelia Huck]

We need to implement the get_dev_path method for the css bus, or
else we might end up with two different devices having the same
qdev_path.

This was noticed when adding two scsi_hd controllers: The SCSIBus
code will produce a non-unique dev_path for vmstate usage if the
parent bus does not provide the get_dev_path method.

We simply use the device's bus id, as this is unique and we won't
have any deeper hierarchy from a channel subsystem perspective
anyway.

Note that we need to disable this for older machine versions,
as this changes the migration format.

Reported-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com>
Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Tested-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
---
 hw/s390x/css-bridge.c         | 26 +++++++++++++++++++++++++-
 hw/s390x/s390-virtio-ccw.c    |  4 ++++
 include/hw/s390x/css-bridge.h |  7 +++++++
 3 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/css-bridge.c b/hw/s390x/css-bridge.c
index e4c24e2..9a7f7ee 100644
--- a/hw/s390x/css-bridge.c
+++ b/hw/s390x/css-bridge.c
@@ -59,11 +59,28 @@ static void virtual_css_bus_reset(BusState *qbus)
     css_reset();
 }
 
+static char *virtual_css_bus_get_dev_path(DeviceState *dev)
+{
+    CcwDevice *ccw_dev = CCW_DEVICE(dev);
+    SubchDev *sch = ccw_dev->sch;
+    VirtualCssBridge *bridge =
+        VIRTUAL_CSS_BRIDGE(qdev_get_parent_bus(dev)->parent);
+
+    /*
+     * We can't provide a dev path for backward compatibility on
+     * older machines, as it is visible in the migration stream.
+     */
+    return bridge->css_dev_path ?
+        g_strdup_printf("/%02x.%1x.%04x", sch->cssid, sch->ssid, sch->devno) :
+        NULL;
+}
+
 static void virtual_css_bus_class_init(ObjectClass *klass, void *data)
 {
     BusClass *k = BUS_CLASS(klass);
 
     k->reset = virtual_css_bus_reset;
+    k->get_dev_path = virtual_css_bus_get_dev_path;
 }
 
 static const TypeInfo virtual_css_bus_info = {
@@ -95,6 +112,12 @@ VirtualCssBus *virtual_css_bus_init(void)
 
 /***************** Virtual-css Bus Bridge Device ********************/
 
+static Property virtual_css_bridge_properties[] = {
+    DEFINE_PROP_BOOL("css_dev_path", VirtualCssBridge, css_dev_path,
+                     true),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
 static void virtual_css_bridge_class_init(ObjectClass *klass, void *data)
 {
     HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
@@ -102,12 +125,13 @@ static void virtual_css_bridge_class_init(ObjectClass *klass, void *data)
 
     hc->unplug = ccw_device_unplug;
     set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
+    dc->props = virtual_css_bridge_properties;
 }
 
 static const TypeInfo virtual_css_bridge_info = {
     .name          = TYPE_VIRTUAL_CSS_BRIDGE,
     .parent        = TYPE_SYS_BUS_DEVICE,
-    .instance_size = sizeof(SysBusDevice),
+    .instance_size = sizeof(VirtualCssBridge),
     .class_init    = virtual_css_bridge_class_init,
     .interfaces = (InterfaceInfo[]) {
         { TYPE_HOTPLUG_HANDLER },
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index caf0a68..91d9cef 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -322,6 +322,10 @@ static const TypeInfo ccw_machine_info = {
             .driver   = TYPE_S390_IPL,\
             .property = "iplbext_migration",\
             .value    = "off",\
+        }, {\
+            .driver   = TYPE_VIRTUAL_CSS_BRIDGE,\
+            .property = "css_dev_path",\
+            .value    = "off",\
         },
 
 #define CCW_COMPAT_2_5 \
diff --git a/include/hw/s390x/css-bridge.h b/include/hw/s390x/css-bridge.h
index ad73c1f..5a0203b 100644
--- a/include/hw/s390x/css-bridge.h
+++ b/include/hw/s390x/css-bridge.h
@@ -16,7 +16,14 @@
 #include "hw/qdev-core.h"
 
 /* virtual css bridge */
+typedef struct VirtualCssBridge {
+    SysBusDevice sysbus_dev;
+    bool css_dev_path;
+} VirtualCssBridge;
+
 #define TYPE_VIRTUAL_CSS_BRIDGE "virtual-css-bridge"
+#define VIRTUAL_CSS_BRIDGE(obj) \
+    OBJECT_CHECK(VirtualCssBridge, (obj), TYPE_VIRTUAL_CSS_BRIDGE)
 
 /* virtual css bus type */
 typedef struct VirtualCssBus {
-- 
2.9.2

Re: [Qemu-devel] [PULL 0/3] s390x fixes for 2.7

[Peter Maydell]

On 20 July 2016 at 15:17, Cornelia Huck <cornelia.huck@de.ibm.com> wrote:
> ck/qemu s390x-20160720
> The following changes since commit 1ecfb24da987b862fd46a5b37292879952ea9e7d:
>
>   Merge remote-tracking branch 'remotes/riku/tags/pull-linux-user-20160719-2' into staging (2016-07-20 11:32:12 +0100)
>
> are available in the git repository at:
>
>   git://github.com/cohuck/qemu tags/s390x-20160720
>
> for you to fetch changes up to 2a79eb1a616a07b0e8c41430f03af254fefe219d:
>
>   s390x/css: provide a dev_path for css devices (2016-07-20 15:47:25 +0200)
>
> ----------------------------------------------------------------
> Fixes for s390x in the css area.
>
> ----------------------------------------------------------------

Applied, thanks.

-- PMM