Skip to content
This repository has been archived by the owner on May 12, 2021. It is now read-only.

s390x: virtio-blk-ccw support #1153

Closed
alicefr opened this issue Jan 18, 2019 · 11 comments · Fixed by #1965
Closed

s390x: virtio-blk-ccw support #1153

alicefr opened this issue Jan 18, 2019 · 11 comments · Fixed by #1965

Comments

@alicefr
Copy link
Member

alicefr commented Jan 18, 2019 •
edited

IBM Z uses ccw devices and the case for 'virtio-blk-ccw' with devicemapper doesn't properly work. It requires a special handling. That probably requires changes in govmm, the agent and the runtime. I saw from #1113 that you might plan to drop the 'virtio-blk'' option. Therefore, I don't know if it's worthy to implement this functionality. The option 'virtio-scsi' works.
@alicefr alicefr mentioned this issue Jan 18, 2019
Closed
50 tasks
@jodh-intel
Copy link
Contributor

/cc @mcastelino, @egernst.

devimc pushed a commit to devimc/kata-runtime that referenced this issue Feb 6, 2019
virtcontainers: reimplement sandbox cgroup
498c7bc 
All containers run in different cgroups even the sandbox, with this new
implementation the sandbox cpu cgroup wil be equal to the sum of all its
containers and the hypervisor process will be placed there impacting to the
containers running in the sandbox (VM). The default number of vcpus is
used when the sandbox has no constraints. For example, if default_vcpus
is 2, then quota will be 200000 and period 100000.

**c-ray test**
http://www.futuretech.blinkenlights.nl/c-ray.html

```
+=============================================+
|         | 6 threads 6cpus | 1 thread 1 cpu  |
+=============================================+
| current |   40 seconds    |   122 seconds   |
+==============================================
|   new   |   37 seconds    |   124 seconds   |
+==============================================
```

current = current cgroups implementation
new = new cgroups implementation

**workload**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: c-ray
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  restartPolicy: Never
  containers:
  - name: c-ray-1
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "6", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 6
  - name: c-ray-2
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "1", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 1
```

Depends-on: github.com/kata-containers/tests#1141

fixes kata-containers#1153

Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc pushed a commit to devimc/kata-runtime that referenced this issue Feb 6, 2019
virtcontainers: reimplement sandbox cgroup
89e8893 
All containers run in different cgroups even the sandbox, with this new
implementation the sandbox cpu cgroup wil be equal to the sum of all its
containers and the hypervisor process will be placed there impacting to the
containers running in the sandbox (VM). The default number of vcpus is
used when the sandbox has no constraints. For example, if default_vcpus
is 2, then quota will be 200000 and period 100000.

**c-ray test**
http://www.futuretech.blinkenlights.nl/c-ray.html

```
+=============================================+
|         | 6 threads 6cpus | 1 thread 1 cpu  |
+=============================================+
| current |   40 seconds    |   122 seconds   |
+==============================================
|   new   |   37 seconds    |   124 seconds   |
+==============================================
```

current = current cgroups implementation
new = new cgroups implementation

**workload**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: c-ray
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  restartPolicy: Never
  containers:
  - name: c-ray-1
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "6", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 6
  - name: c-ray-2
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "1", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 1
```

Depends-on: github.com/kata-containers/tests#1141

fixes kata-containers#1153

Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc pushed a commit to devimc/kata-runtime that referenced this issue Feb 6, 2019
virtcontainers: reimplement sandbox cgroup
01c86c3 
All containers run in different cgroups even the sandbox, with this new
implementation the sandbox cpu cgroup wil be equal to the sum of all its
containers and the hypervisor process will be placed there impacting to the
containers running in the sandbox (VM). The default number of vcpus is
used when the sandbox has no constraints. For example, if default_vcpus
is 2, then quota will be 200000 and period 100000.

**c-ray test**
http://www.futuretech.blinkenlights.nl/c-ray.html

```
+=============================================+
|         | 6 threads 6cpus | 1 thread 1 cpu  |
+=============================================+
| current |   40 seconds    |   122 seconds   |
+==============================================
|   new   |   37 seconds    |   124 seconds   |
+==============================================
```

current = current cgroups implementation
new = new cgroups implementation

**workload**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: c-ray
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  restartPolicy: Never
  containers:
  - name: c-ray-1
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "6", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 6
  - name: c-ray-2
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "1", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 1
```

fixes kata-containers#1153

Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc pushed a commit to devimc/kata-runtime that referenced this issue Feb 7, 2019
virtcontainers: reimplement sandbox cgroup
b501c72 
All containers run in different cgroups even the sandbox, with this new
implementation the sandbox cpu cgroup wil be equal to the sum of all its
containers and the hypervisor process will be placed there impacting to the
containers running in the sandbox (VM). The default number of vcpus is
used when the sandbox has no constraints. For example, if default_vcpus
is 2, then quota will be 200000 and period 100000.

**c-ray test**
http://www.futuretech.blinkenlights.nl/c-ray.html

```
+=============================================+
|         | 6 threads 6cpus | 1 thread 1 cpu  |
+=============================================+
| current |   40 seconds    |   122 seconds   |
+==============================================
|   new   |   37 seconds    |   124 seconds   |
+==============================================
```

current = current cgroups implementation
new = new cgroups implementation

**workload**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: c-ray
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  restartPolicy: Never
  containers:
  - name: c-ray-1
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "6", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 6
  - name: c-ray-2
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "1", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 1
```

fixes kata-containers#1153

Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc pushed a commit to devimc/kata-runtime that referenced this issue Feb 12, 2019
virtcontainers: reimplement sandbox cgroup
ac0f77d 
All containers run in different cgroups even the sandbox, with this new
implementation the sandbox cpu cgroup wil be equal to the sum of all its
containers and the hypervisor process will be placed there impacting to the
containers running in the sandbox (VM). The default number of vcpus is
used when the sandbox has no constraints. For example, if default_vcpus
is 2, then quota will be 200000 and period 100000.

**c-ray test**
http://www.futuretech.blinkenlights.nl/c-ray.html

```
+=============================================+
|         | 6 threads 6cpus | 1 thread 1 cpu  |
+=============================================+
| current |   40 seconds    |   122 seconds   |
+==============================================
|   new   |   37 seconds    |   124 seconds   |
+==============================================
```

current = current cgroups implementation
new = new cgroups implementation

**workload**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: c-ray
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  restartPolicy: Never
  containers:
  - name: c-ray-1
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "6", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 6
  - name: c-ray-2
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "1", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 1
```

fixes kata-containers#1153

Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc pushed a commit to devimc/kata-runtime that referenced this issue Feb 12, 2019
virtcontainers: reimplement sandbox cgroup
d312758 
All containers run in different cgroups even the sandbox, with this new
implementation the sandbox cpu cgroup wil be equal to the sum of all its
containers and the hypervisor process will be placed there impacting to the
containers running in the sandbox (VM). The default number of vcpus is
used when the sandbox has no constraints. For example, if default_vcpus
is 2, then quota will be 200000 and period 100000.

**c-ray test**
http://www.futuretech.blinkenlights.nl/c-ray.html

```
+=============================================+
|         | 6 threads 6cpus | 1 thread 1 cpu  |
+=============================================+
| current |   40 seconds    |   122 seconds   |
+==============================================
|   new   |   37 seconds    |   124 seconds   |
+==============================================
```

current = current cgroups implementation
new = new cgroups implementation

**workload**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: c-ray
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  restartPolicy: Never
  containers:
  - name: c-ray-1
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "6", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 6
  - name: c-ray-2
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "1", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 1
```

fixes kata-containers#1153

Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc pushed a commit to devimc/kata-runtime that referenced this issue Feb 12, 2019
virtcontainers: reimplement sandbox cgroup
9bd48de 
All containers run in different cgroups even the sandbox, with this new
implementation the sandbox cpu cgroup wil be equal to the sum of all its
containers and the hypervisor process will be placed there impacting to the
containers running in the sandbox (VM). The default number of vcpus is
used when the sandbox has no constraints. For example, if default_vcpus
is 2, then quota will be 200000 and period 100000.

**c-ray test**
http://www.futuretech.blinkenlights.nl/c-ray.html

```
+=============================================+
|         | 6 threads 6cpus | 1 thread 1 cpu  |
+=============================================+
| current |   40 seconds    |   122 seconds   |
+==============================================
|   new   |   37 seconds    |   124 seconds   |
+==============================================
```

current = current cgroups implementation
new = new cgroups implementation

**workload**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: c-ray
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  restartPolicy: Never
  containers:
  - name: c-ray-1
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "6", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 6
  - name: c-ray-2
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "1", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 1
```

fixes kata-containers#1153

Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc pushed a commit to devimc/kata-runtime that referenced this issue Feb 13, 2019
virtcontainers: reimplement sandbox cgroup
a58d076 
All containers run in different cgroups even the sandbox, with this new
implementation the sandbox cpu cgroup wil be equal to the sum of all its
containers and the hypervisor process will be placed there impacting to the
containers running in the sandbox (VM). The default number of vcpus is
used when the sandbox has no constraints. For example, if default_vcpus
is 2, then quota will be 200000 and period 100000.

**c-ray test**
http://www.futuretech.blinkenlights.nl/c-ray.html

```
+=============================================+
|         | 6 threads 6cpus | 1 thread 1 cpu  |
+=============================================+
| current |   40 seconds    |   122 seconds   |
+==============================================
|   new   |   37 seconds    |   124 seconds   |
+==============================================
```

current = current cgroups implementation
new = new cgroups implementation

**workload**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: c-ray
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  restartPolicy: Never
  containers:
  - name: c-ray-1
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "6", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 6
  - name: c-ray-2
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "1", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 1
```

fixes kata-containers#1153

Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc pushed a commit to devimc/kata-runtime that referenced this issue Feb 14, 2019
virtcontainers: reimplement sandbox cgroup
f0d99e1 
All containers run in different cgroups even the sandbox, with this new
implementation the sandbox cpu cgroup wil be equal to the sum of all its
containers and the hypervisor process will be placed there impacting to the
containers running in the sandbox (VM). The default number of vcpus is
used when the sandbox has no constraints. For example, if default_vcpus
is 2, then quota will be 200000 and period 100000.

**c-ray test**
http://www.futuretech.blinkenlights.nl/c-ray.html

```
+=============================================+
|         | 6 threads 6cpus | 1 thread 1 cpu  |
+=============================================+
| current |   40 seconds    |   122 seconds   |
+==============================================
|   new   |   37 seconds    |   124 seconds   |
+==============================================
```

current = current cgroups implementation
new = new cgroups implementation

**workload**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: c-ray
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  restartPolicy: Never
  containers:
  - name: c-ray-1
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "6", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 6
  - name: c-ray-2
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "1", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 1
```

fixes kata-containers#1153

Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc pushed a commit to devimc/kata-runtime that referenced this issue Feb 18, 2019
virtcontainers: reimplement sandbox cgroup
39d24e8 
All containers run in different cgroups even the sandbox, with this new
implementation the sandbox cpu cgroup wil be equal to the sum of all its
containers and the hypervisor process will be placed there impacting to the
containers running in the sandbox (VM). The default number of vcpus is
used when the sandbox has no constraints. For example, if default_vcpus
is 2, then quota will be 200000 and period 100000.

**c-ray test**
http://www.futuretech.blinkenlights.nl/c-ray.html

```
+=============================================+
|         | 6 threads 6cpus | 1 thread 1 cpu  |
+=============================================+
| current |   40 seconds    |   122 seconds   |
+==============================================
|   new   |   37 seconds    |   124 seconds   |
+==============================================
```

current = current cgroups implementation
new = new cgroups implementation

**workload**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: c-ray
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  restartPolicy: Never
  containers:
  - name: c-ray-1
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "6", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 6
  - name: c-ray-2
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "1", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 1
```

fixes kata-containers#1153

Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc pushed a commit to devimc/kata-runtime that referenced this issue Feb 18, 2019
virtcontainers: reimplement sandbox cgroup
c15d54f 
All containers run in different cgroups even the sandbox, with this new
implementation the sandbox cpu cgroup wil be equal to the sum of all its
containers and the hypervisor process will be placed there impacting to the
containers running in the sandbox (VM). The default number of vcpus is
used when the sandbox has no constraints. For example, if default_vcpus
is 2, then quota will be 200000 and period 100000.

**c-ray test**
http://www.futuretech.blinkenlights.nl/c-ray.html

```
+=============================================+
|         | 6 threads 6cpus | 1 thread 1 cpu  |
+=============================================+
| current |   40 seconds    |   122 seconds   |
+==============================================
|   new   |   37 seconds    |   124 seconds   |
+==============================================
```

current = current cgroups implementation
new = new cgroups implementation

**workload**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: c-ray
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  restartPolicy: Never
  containers:
  - name: c-ray-1
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "6", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 6
  - name: c-ray-2
    image: docker.io/devimc/c-ray:latest
    imagePullPolicy: IfNotPresent
    args: ["-t", "1", "-s", "1600x1200", "-r", "8", "-i",
          "/c-ray-1.1/sphfract", "-o", "/tmp/output.ppm"]
    resources:
      limits:
        cpu: 1
```

fixes kata-containers#1153

Signed-off-by: Julio Montes <julio.montes@intel.com>
@GabyCT GabyCT closed this as completed in 5201860 Feb 20, 2019
@caoruidong
Copy link
Member

Wrong fixes ...

@caoruidong caoruidong reopened this Feb 21, 2019
@alicefr
Copy link
Member Author

alicefr commented Feb 21, 2019

:) thanks to re-open it! @tuan-hoang1 is working on this part

@alicefr alicefr mentioned this issue Apr 15, 2019
Closed
@alicefr
Copy link
Member Author

alicefr commented Jul 4, 2019 •
edited

I extended kata to support virtio-blk-ccw devices for s390x. Differently to pci devices, ccw devices can be identified by the param devno(device_bus_id). The devices information during the hotplug are updated under'/sys/devices/css0/', and the disk name can be found under '/sys/bus/ccw/devices'
This requires several modifications:

There're several modifications to the code and I'm not sure how to split the various modification to ease the review. I was thinking to open 2 PRs:
1- with the abstraction of pcibridge and the support of ccw
2- addition of devno param and virtio-blk-ccw

@grahamwhaley
Copy link
Contributor

grahamwhaley commented Jul 4, 2019 •
edited

/cc @amshinde @devimc for any input on device model etc.

This was referenced Jul 4, 2019
Closed
Merged
@alicefr alicefr changed the title s390x: virtio-blk not supported yet s390x: virtio-blk support Jul 5, 2019
@alicefr
Copy link
Member Author

alicefr commented Jul 5, 2019 •
edited

The vendoring of govmm can be done together with this PR #1843 or I'll do on top. I need in any case the updated signature for 2 functions already included in that PR

@alicefr
Copy link
Member Author

alicefr commented Jul 5, 2019 •
edited

Can I open a PR with the rest of my changes for the virtio-blk-ccw with the do-not-merge tag? I'd really appreciate any suggestions how to split it and also if you like my changes in the common code. Currently my code can be found here.

@alicefr alicefr changed the title s390x: virtio-blk support s390x: virtio-blk-ccw support Jul 5, 2019
@alicefr
Copy link
Member Author

alicefr commented Aug 5, 2019

hi, thanks to merging the agent part. Now, the missing part is the runtime. @jschintag and I we noticed today that you revendor govmm. The new version inlcuded the devno support. However, the runtime part is missing and the qemu cmd line is broken (for s390x). It has an empty value for devno. Something like qemu-system-s390x: -device virtio-serial-ccw,id=serial0,devno=. So no wonder if now the runtime for s390x is not working properly. I've already prepared the code. But it's complicate because I extended the PCI bridge and this requires some code review.

@alicefr
Copy link
Member Author

alicefr commented Aug 5, 2019

I'd suggest that I open a PR with the code with a dont-merge tag, is it ok for you?

@jschintag jschintag mentioned this issue Aug 5, 2019
Closed
jschintag pushed a commit to jschintag/kata-runtime that referenced this issue Aug 26, 2019
@jschintag
virtcontainers: create generic function
9debe98 
Create generic function to be reused to the reimplemented methods by
various architectures

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag pushed a commit to jschintag/kata-runtime that referenced this issue Aug 26, 2019
@jschintag
virtcontainers: add devno
a62f496 
The devno number is use to identify the device on IBM Z arch.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag added a commit to jschintag/kata-runtime that referenced this issue Aug 26, 2019
@jschintag
s390x: add virtio-blk-ccw
590e9e8 
Add virtio-blk-ccw support

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag added a commit to jschintag/kata-runtime that referenced this issue Aug 28, 2019
@jschintag
bridges: Check if this fixes netmon error
4d55774 
TODO: Put changes into right commits

Fixes: kata-containers#1153
Signed-off-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag added a commit to jschintag/kata-runtime that referenced this issue Aug 28, 2019
@jschintag
bridges: abstraction of bridge type
9887b4f 
The abstraction of the bridge type to add additional types.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Co-authored-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag added a commit to jschintag/kata-runtime that referenced this issue Aug 28, 2019
@jschintag
virtcontainers: Move bridge var in qemu type
0295157 
In this way it is possible to set bridge variable for each arch when
instantiating the hypervisor.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Co-authored-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag pushed a commit to jschintag/kata-runtime that referenced this issue Aug 28, 2019
@jschintag
ccw: add ccw type as bridge
285729a 
On IBM Z, CCW bus type can be additionally used.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag pushed a commit to jschintag/kata-runtime that referenced this issue Aug 28, 2019
@jschintag
virtcontainers: create generic function
bc06de1 
Create generic function to be reused to the reimplemented methods by
various architectures

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag pushed a commit to jschintag/kata-runtime that referenced this issue Aug 28, 2019
@jschintag
virtcontainers: add devno
ccde04d 
The devno number is use to identify the device on IBM Z arch.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag added a commit to jschintag/kata-runtime that referenced this issue Aug 28, 2019
@jschintag
s390x: add virtio-blk-ccw
7682a62 
Add virtio-blk-ccw support

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag added a commit to jschintag/kata-runtime that referenced this issue Aug 29, 2019
@jschintag
virtcontainers: Move bridge var in qemu type
9f5ca69 
In this way it is possible to set bridge variable for each arch when
instantiating the hypervisor.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Co-authored-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag pushed a commit to jschintag/kata-runtime that referenced this issue Aug 29, 2019
@jschintag
ccw: add ccw type as bridge
f277a71 
On IBM Z, CCW bus type can be additionally used.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag pushed a commit to jschintag/kata-runtime that referenced this issue Aug 29, 2019
@jschintag
virtcontainers: create generic function
d37d9bf 
Create generic function to be reused to the reimplemented methods by
various architectures

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag pushed a commit to jschintag/kata-runtime that referenced this issue Aug 29, 2019
@jschintag
virtcontainers: add devno
47bfc06 
The devno number is use to identify the device on IBM Z arch.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag added a commit to jschintag/kata-runtime that referenced this issue Aug 29, 2019
@jschintag
s390x: add virtio-blk-ccw
bd066ad 
Add virtio-blk-ccw support

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag added a commit to jschintag/kata-runtime that referenced this issue Aug 30, 2019
@jschintag
s390x: add virtio-blk-ccw
2d7de41 
Add virtio-blk-ccw support

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag added a commit to jschintag/kata-runtime that referenced this issue Aug 30, 2019
@jschintag
s390x: add virtio-blk-ccw
827e41f 
Add virtio-blk-ccw support

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag added a commit to jschintag/kata-runtime that referenced this issue Sep 2, 2019
@jschintag
bridges: abstraction of bridge type
9188774 
The abstraction of the bridge type to add additional types.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Co-authored-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag added a commit to jschintag/kata-runtime that referenced this issue Sep 2, 2019
@jschintag
virtcontainers: Move bridge var in qemu type
23e6073 
In this way it is possible to set bridge variable for each arch when
instantiating the hypervisor.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Co-authored-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag pushed a commit to jschintag/kata-runtime that referenced this issue Sep 2, 2019
@jschintag
ccw: add ccw type as bridge
e99739f 
On IBM Z, CCW bus type can be additionally used.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag pushed a commit to jschintag/kata-runtime that referenced this issue Sep 2, 2019
@jschintag
virtcontainers: create generic function
7eec670 
Create generic function to be reused to the reimplemented methods by
various architectures

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag pushed a commit to jschintag/kata-runtime that referenced this issue Sep 2, 2019
@jschintag
virtcontainers: add devno
d627585 
The devno number is use to identify the device on IBM Z arch.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
jschintag added a commit to jschintag/kata-runtime that referenced this issue Sep 2, 2019
@jschintag
s390x: add virtio-blk-ccw
b075b5c 
Add virtio-blk-ccw support

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
alicefr pushed a commit to alicefr/runtime that referenced this issue Sep 5, 2019
@jschintag
bridges: abstraction of bridge type
57a5f63 
The abstraction of the bridge type to add additional types.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Co-authored-by: Jan Schintag <jan.schintag@de.ibm.com>
alicefr pushed a commit to alicefr/runtime that referenced this issue Sep 5, 2019
@jschintag
virtcontainers: Move bridge var in qemu type
5f2950a 
In this way it is possible to set bridge variable for each arch when
instantiating the hypervisor.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Co-authored-by: Jan Schintag <jan.schintag@de.ibm.com>
alicefr pushed a commit to alicefr/runtime that referenced this issue Sep 5, 2019
ccw: add ccw type as bridge
67ac3d5 
On IBM Z, CCW bus type can be additionally used.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
alicefr pushed a commit to alicefr/runtime that referenced this issue Sep 5, 2019
virtcontainers: create generic function
9feef89 
Create generic function to be reused to the reimplemented methods by
various architectures

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
alicefr pushed a commit to alicefr/runtime that referenced this issue Sep 5, 2019
virtcontainers: add devno
5f2c193 
The devno number is use to identify the device on IBM Z arch.

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
alicefr pushed a commit to alicefr/runtime that referenced this issue Sep 5, 2019
@jschintag
s390x: add virtio-blk-ccw
29b4799 
Add virtio-blk-ccw support

Fixes: kata-containers#1153

Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
Reviewed-by: Jan Schintag <jan.schintag@de.ibm.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

s390x: add virtio-blk-ccw support jschintag/kata-runtime
4 participants
@grahamwhaley @caoruidong @jodh-intel @alicefr