[Qemu-devel] [RFC v3 0/4] vITS Reset

[Qemu-devel] [RFC v3 0/4] vITS Reset

[Eric Auger]

At the moment the ITS is not properly reset. On System reset or
reboot, previous ITS register values and caches are left
unchanged. Some of the registers might point to some guest RAM
tables which are not valid anymore. This leads to state
inconsistencies that are detected by the kernel save/restore
code. And eventually this may cause qemu abort.

This series adds vITS reset modality:
- the 2 first patches bring a minimalist reset through individual
  register writes. However, with kernel versions < 4.15, this reset
  is not complete (vITS caches are not voided).
- With kernel versions >= 4.15 we can rely on a new ITS KVM device
  reset IOTCL. The last 2 patches introduce the full reset.

Patches 1-2 have all kernel dependencies resolved.
Patches 3-4' dependencies were pulled for v4.15-rc0 but as the tag is
not set, the kernel header update still is partial.

Best Regards

Eric

The series is available at:
https://github.com/eauger/qemu/tree/2.11.0-rc2-its-reset-v3

History:
v2 -> v3:
- don't call post_load on reset (no iidr check anymore)

v1 -> v2:
- Clarify why abort should be removed for save. Leave abort
  for restore.
- Adopt the same reset infra as vgic
- introduce "hw/intc/arm_gicv3_its: Implement a minimalist reset"
  which perform individual register writes. This is sufficient to
  fix the issues without ioctl


Eric Auger (4):
  hw/intc/arm_gicv3_its: Don't call post_load on reset
  hw/intc/arm_gicv3_its: Implement a minimalist reset
  linux-headers: Partial header update for ITS reset
  hw/intc/arm_gicv3_its: Implement full reset

 hw/intc/arm_gicv3_its_common.c |  2 --
 hw/intc/arm_gicv3_its_kvm.c    | 52 ++++++++++++++++++++++++++++++++++++++----
 linux-headers/asm-arm/kvm.h    |  1 +
 linux-headers/asm-arm64/kvm.h  |  1 +
 4 files changed, 50 insertions(+), 6 deletions(-)

-- 
2.5.5

[Qemu-devel] [RFC v3 1/4] hw/intc/arm_gicv3_its: Don't call post_load on reset

[Eric Auger]

>From the very beginning, post_load() was called from common
reset. This is not standard and obliged to discriminate the
reset case from the restore case using the iidr value.

Let's get rid of that call.

Signed-off-by: Eric Auger <eric.auger@redhat.com>
---
 hw/intc/arm_gicv3_its_common.c | 2 --
 hw/intc/arm_gicv3_its_kvm.c    | 4 ----
 2 files changed, 6 deletions(-)

diff --git a/hw/intc/arm_gicv3_its_common.c b/hw/intc/arm_gicv3_its_common.c
index f2cce59..2bd2f0f 100644
--- a/hw/intc/arm_gicv3_its_common.c
+++ b/hw/intc/arm_gicv3_its_common.c
@@ -131,8 +131,6 @@ static void gicv3_its_common_reset(DeviceState *dev)
     s->creadr = 0;
     s->iidr = 0;
     memset(&s->baser, 0, sizeof(s->baser));
-
-    gicv3_its_post_load(s, 0);
 }
 
 static void gicv3_its_common_class_init(ObjectClass *klass, void *data)
diff --git a/hw/intc/arm_gicv3_its_kvm.c b/hw/intc/arm_gicv3_its_kvm.c
index 6fb45df..b1b322b 100644
--- a/hw/intc/arm_gicv3_its_kvm.c
+++ b/hw/intc/arm_gicv3_its_kvm.c
@@ -155,10 +155,6 @@ static void kvm_arm_its_post_load(GICv3ITSState *s)
 {
     int i;
 
-    if (!s->iidr) {
-        return;
-    }
-
     kvm_device_access(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_ITS_REGS,
                       GITS_IIDR, &s->iidr, true, &error_abort);
 
-- 
2.5.5

[Qemu-devel] [RFC v3 2/4] hw/intc/arm_gicv3_its: Implement a minimalist reset

[Eric Auger]

At the moment the ITS is not properly reset and this causes
various bugs on save/restore. We implement a minimalist reset
through individual register writes but for kernel versions
before v4.15 this fails voiding the vITS cache. We cannot
claim we have a comprehensive reset (hence the error message)
but that's better than nothing.

Signed-off-by: Eric Auger <eric.auger@redhat.com>

---

v2 -> v3:
- individual register writes performed in kvm_arm_its_reset
- check KVM_DEV_ARM_VGIC_GRP_ITS_REGS support
---
 hw/intc/arm_gicv3_its_kvm.c | 41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/hw/intc/arm_gicv3_its_kvm.c b/hw/intc/arm_gicv3_its_kvm.c
index b1b322b..83e5268 100644
--- a/hw/intc/arm_gicv3_its_kvm.c
+++ b/hw/intc/arm_gicv3_its_kvm.c
@@ -28,6 +28,16 @@
 
 #define TYPE_KVM_ARM_ITS "arm-its-kvm"
 #define KVM_ARM_ITS(obj) OBJECT_CHECK(GICv3ITSState, (obj), TYPE_KVM_ARM_ITS)
+#define KVM_ARM_ITS_CLASS(klass) \
+     OBJECT_CLASS_CHECK(KVMARMITSClass, (klass), TYPE_KVM_ARM_ITS)
+#define KVM_ARM_ITS_GET_CLASS(obj) \
+     OBJECT_GET_CLASS(KVMARMITSClass, (obj), TYPE_KVM_ARM_ITS)
+
+typedef struct KVMARMITSClass {
+    GICv3ITSCommonClass parent_class;
+    void (*parent_reset)(DeviceState *dev);
+} KVMARMITSClass;
+
 
 static int kvm_its_send_msi(GICv3ITSState *s, uint32_t value, uint16_t devid)
 {
@@ -186,6 +196,34 @@ static void kvm_arm_its_post_load(GICv3ITSState *s)
                       GITS_CTLR, &s->ctlr, true, &error_abort);
 }
 
+static void kvm_arm_its_reset(DeviceState *dev)
+{
+    GICv3ITSState *s = ARM_GICV3_ITS_COMMON(dev);
+    KVMARMITSClass *c = KVM_ARM_ITS_GET_CLASS(s);
+    int i;
+
+    c->parent_reset(dev);
+
+    error_report("ITS KVM: full reset is not supported by the host kernel");
+
+    if (!kvm_device_check_attr(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_ITS_REGS,
+                               GITS_CTLR)) {
+        return;
+    }
+
+    kvm_device_access(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_ITS_REGS,
+                      GITS_CTLR, &s->ctlr, true, &error_abort);
+
+    kvm_device_access(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_ITS_REGS,
+                      GITS_CBASER, &s->cbaser, true, &error_abort);
+
+    for (i = 0; i < 8; i++) {
+        kvm_device_access(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_ITS_REGS,
+                          GITS_BASER + i * 8, &s->baser[i], true,
+                          &error_abort);
+    }
+}
+
 static Property kvm_arm_its_props[] = {
     DEFINE_PROP_LINK("parent-gicv3", GICv3ITSState, gicv3, "kvm-arm-gicv3",
                      GICv3State *),
@@ -196,12 +234,15 @@ static void kvm_arm_its_class_init(ObjectClass *klass, void *data)
 {
     DeviceClass *dc = DEVICE_CLASS(klass);
     GICv3ITSCommonClass *icc = ARM_GICV3_ITS_COMMON_CLASS(klass);
+    KVMARMITSClass *ic = KVM_ARM_ITS_CLASS(klass);
 
     dc->realize = kvm_arm_its_realize;
     dc->props   = kvm_arm_its_props;
+    ic->parent_reset = dc->reset;
     icc->send_msi = kvm_its_send_msi;
     icc->pre_save = kvm_arm_its_pre_save;
     icc->post_load = kvm_arm_its_post_load;
+    dc->reset = kvm_arm_its_reset;
 }
 
 static const TypeInfo kvm_arm_its_info = {
-- 
2.5.5

[Qemu-devel] [RFC v3 3/4] linux-headers: Partial header update for ITS reset

[Eric Auger]

This aims at importing the KVM_DEV_ARM_ITS_CTRL_RESET attribute
which allows to trigger a reset of the in-kernel emulated ITS.

This is now upstream but not tagged yet with v4.15-rc0

Signed-off-by: Eric Auger <eric.auger@redhat.com>
---
 linux-headers/asm-arm/kvm.h   | 1 +
 linux-headers/asm-arm64/kvm.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/linux-headers/asm-arm/kvm.h b/linux-headers/asm-arm/kvm.h
index fa9fae8..8dd0ba7 100644
--- a/linux-headers/asm-arm/kvm.h
+++ b/linux-headers/asm-arm/kvm.h
@@ -215,6 +215,7 @@ struct kvm_arch_memory_slot {
 #define   KVM_DEV_ARM_ITS_SAVE_TABLES		1
 #define   KVM_DEV_ARM_ITS_RESTORE_TABLES	2
 #define   KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES	3
+#define   KVM_DEV_ARM_ITS_CTRL_RESET		4
 
 /* KVM_IRQ_LINE irq field index values */
 #define KVM_ARM_IRQ_TYPE_SHIFT		24
diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
index d254700..2585a50 100644
--- a/linux-headers/asm-arm64/kvm.h
+++ b/linux-headers/asm-arm64/kvm.h
@@ -227,6 +227,7 @@ struct kvm_arch_memory_slot {
 #define   KVM_DEV_ARM_ITS_SAVE_TABLES           1
 #define   KVM_DEV_ARM_ITS_RESTORE_TABLES        2
 #define   KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES	3
+#define   KVM_DEV_ARM_ITS_CTRL_RESET		4
 
 /* Device Control API on vcpu fd */
 #define KVM_ARM_VCPU_PMU_V3_CTRL	0
-- 
2.5.5

[Qemu-devel] [RFC v3 4/4] hw/intc/arm_gicv3_its: Implement full reset

[Eric Auger]

Voiding the ITS caches is not supposed to happen via
individual register writes. So we introduced a dedicated
ITS KVM device ioctl to perform a cold reset of the ITS:
KVM_DEV_ARM_VGIC_GRP_CTRL/KVM_DEV_ARM_ITS_CTRL_RESET. Let's
use this latter if the kernel supports it.

Signed-off-by: Eric Auger <eric.auger@redhat.com>
---
 hw/intc/arm_gicv3_its_kvm.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/hw/intc/arm_gicv3_its_kvm.c b/hw/intc/arm_gicv3_its_kvm.c
index 83e5268..bad593f 100644
--- a/hw/intc/arm_gicv3_its_kvm.c
+++ b/hw/intc/arm_gicv3_its_kvm.c
@@ -204,6 +204,13 @@ static void kvm_arm_its_reset(DeviceState *dev)
 
     c->parent_reset(dev);
 
+    if (kvm_device_check_attr(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_CTRL,
+                               KVM_DEV_ARM_ITS_CTRL_RESET)) {
+        kvm_device_access(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_CTRL,
+                          KVM_DEV_ARM_ITS_CTRL_RESET, NULL, true, &error_abort);
+        return;
+    }
+
     error_report("ITS KVM: full reset is not supported by the host kernel");
 
     if (!kvm_device_check_attr(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_ITS_REGS,
-- 
2.5.5

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

[Peter Maydell]

On 23 November 2017 at 14:56, Eric Auger <eric.auger@redhat.com> wrote:
> At the moment the ITS is not properly reset. On System reset or
> reboot, previous ITS register values and caches are left
> unchanged. Some of the registers might point to some guest RAM
> tables which are not valid anymore. This leads to state
> inconsistencies that are detected by the kernel save/restore
> code. And eventually this may cause qemu abort.
>
> This series adds vITS reset modality:
> - the 2 first patches bring a minimalist reset through individual
>   register writes. However, with kernel versions < 4.15, this reset
>   is not complete (vITS caches are not voided).
> - With kernel versions >= 4.15 we can rely on a new ITS KVM device
>   reset IOTCL. The last 2 patches introduce the full reset.
>
> Patches 1-2 have all kernel dependencies resolved.
> Patches 3-4' dependencies were pulled for v4.15-rc0 but as the tag is
> not set, the kernel header update still is partial.

We don't need the change to be tagged for us to sync with the
kernel headers: if it's in mainline that's good enough.

thanks
-- PMM

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

[Auger Eric]

Hi Peter,

On 23/11/17 16:19, Peter Maydell wrote:
> On 23 November 2017 at 14:56, Eric Auger <eric.auger@redhat.com> wrote:
>> At the moment the ITS is not properly reset. On System reset or
>> reboot, previous ITS register values and caches are left
>> unchanged. Some of the registers might point to some guest RAM
>> tables which are not valid anymore. This leads to state
>> inconsistencies that are detected by the kernel save/restore
>> code. And eventually this may cause qemu abort.
>>
>> This series adds vITS reset modality:
>> - the 2 first patches bring a minimalist reset through individual
>>   register writes. However, with kernel versions < 4.15, this reset
>>   is not complete (vITS caches are not voided).
>> - With kernel versions >= 4.15 we can rely on a new ITS KVM device
>>   reset IOTCL. The last 2 patches introduce the full reset.
>>
>> Patches 1-2 have all kernel dependencies resolved.
>> Patches 3-4' dependencies were pulled for v4.15-rc0 but as the tag is
>> not set, the kernel header update still is partial.
> 
> We don't need the change to be tagged for us to sync with the
> kernel headers: if it's in mainline that's good enough.

OK. do you allow me to keep a partial update for:
 linux-headers/asm-arm/kvm.h
 linux-headers/asm-arm64/kvm.h?

When using update-linux-headers.sh I get suspicious errors at the end:
grep: /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such file or
directory
sed: can't read /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such
file or directory

and include/standard-headers/asm-s390/virtio-ccw.h deleted

I would prefer having s390 people checking and testing that.

Thanks

Eric

> 
> thanks
> -- PMM
> 

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

[Peter Maydell]

On 23 November 2017 at 16:05, Auger Eric <eric.auger@redhat.com> wrote:
> When using update-linux-headers.sh I get suspicious errors at the end:
> grep: /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such file or
> directory
> sed: can't read /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such
> file or directory
>
> and include/standard-headers/asm-s390/virtio-ccw.h deleted
>
> I would prefer having s390 people checking and testing that.

I think the kvm_virtio.h problem should be fixed by
http://patchwork.ozlabs.org/patch/838230/
which removes it from the set of headers the script imports.

Cornelia/Christian -- any idea about the virtio-ccw.h issue ?

thanks
-- PMM

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

[Cornelia Huck]

On Thu, 23 Nov 2017 17:01:32 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On 23 November 2017 at 16:05, Auger Eric <eric.auger@redhat.com> wrote:
> > When using update-linux-headers.sh I get suspicious errors at the end:
> > grep: /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such file or
> > directory
> > sed: can't read /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such
> > file or directory
> >
> > and include/standard-headers/asm-s390/virtio-ccw.h deleted
> >
> > I would prefer having s390 people checking and testing that.  
> 
> I think the kvm_virtio.h problem should be fixed by
> http://patchwork.ozlabs.org/patch/838230/
> which removes it from the set of headers the script imports.
> 
> Cornelia/Christian -- any idea about the virtio-ccw.h issue ?
> 
> thanks
> -- PMM

I had that commit queued for post-2.11, but I can also send it for 2.11.

The virtio-ccw.h one looks weird... if I run the script on my s390-next
branch against recent-ish Linux master, I just get the SPDX notice
update for virtio-ccw.h.

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

[Auger Eric]

Hi Cornelia, Peter,

On 23/11/17 18:14, Cornelia Huck wrote:
> On Thu, 23 Nov 2017 17:01:32 +0000
> Peter Maydell <peter.maydell@linaro.org> wrote:
> 
>> On 23 November 2017 at 16:05, Auger Eric <eric.auger@redhat.com> wrote:
>>> When using update-linux-headers.sh I get suspicious errors at the end:
>>> grep: /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such file or
>>> directory
>>> sed: can't read /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such
>>> file or directory
>>>
>>> and include/standard-headers/asm-s390/virtio-ccw.h deleted
>>>
>>> I would prefer having s390 people checking and testing that.  
>>
>> I think the kvm_virtio.h problem should be fixed by
>> http://patchwork.ozlabs.org/patch/838230/
>> which removes it from the set of headers the script imports.
>>
>> Cornelia/Christian -- any idea about the virtio-ccw.h issue ?
>>
>> thanks
>> -- PMM
> 
> I had that commit queued for post-2.11, but I can also send it for 2.11.
> 
> The virtio-ccw.h one looks weird... if I run the script on my s390-next
> branch against recent-ish Linux master, I just get the SPDX notice
> update for virtio-ccw.h.
> 

http://patchwork.ozlabs.org/patch/838230/ effectively fixes all issues:
- no errors anymore and
- no deletion of include/standard-headers/asm-s390/virtio-ccw.h anymore,
which is consistent with include/standard-headers/asm-s390/virtio-ccw.h.


Thanks

Eric

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

[Christian Borntraeger]

On 11/23/2017 06:44 PM, Auger Eric wrote:
> Hi Cornelia, Peter,
> 
> On 23/11/17 18:14, Cornelia Huck wrote:
>> On Thu, 23 Nov 2017 17:01:32 +0000
>> Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>>> On 23 November 2017 at 16:05, Auger Eric <eric.auger@redhat.com> wrote:
>>>> When using update-linux-headers.sh I get suspicious errors at the end:
>>>> grep: /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such file or
>>>> directory
>>>> sed: can't read /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such
>>>> file or directory
>>>>
>>>> and include/standard-headers/asm-s390/virtio-ccw.h deletedch
>>>>
>>>> I would prefer having s390 people checking and testing that.  
>>>
>>> I think the kvm_virtio.h problem should be fixed by
>>> http://patchwork.ozlabs.org/patch/838230/
>>> which removes it from the set of headers the script imports.
>>>
>>> Cornelia/Christian -- any idea about the virtio-ccw.h issue ?
>>>
>>> thanks
>>> -- PMM
>>
>> I had that commit queued for post-2.11, but I can also send it for 2.11.
>>
>> The virtio-ccw.h one looks weird... if I run the script on my s390-next
>> branch against recent-ish Linux master, I just get the SPDX notice
>> update for virtio-ccw.h.
>>
> 
> http://patchwork.ozlabs.org/patch/838230/ effectively fixes all issues:
> - no errors anymore and
> - no deletion of include/standard-headers/asm-s390/virtio-ccw.h anymore,
> which is consistent with include/standard-headers/asm-s390/virtio-ccw.h.
> 

I assume the vITS code is post 2.11? If not, we can certainly submit 3 or 4 
s390 patches (including 838230) for 2.11.

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

[Auger Eric]

Hi,

On 23/11/17 19:01, Christian Borntraeger wrote:
> 
> 
> On 11/23/2017 06:44 PM, Auger Eric wrote:
>> Hi Cornelia, Peter,
>>
>> On 23/11/17 18:14, Cornelia Huck wrote:
>>> On Thu, 23 Nov 2017 17:01:32 +0000
>>> Peter Maydell <peter.maydell@linaro.org> wrote:
>>>
>>>> On 23 November 2017 at 16:05, Auger Eric <eric.auger@redhat.com> wrote:
>>>>> When using update-linux-headers.sh I get suspicious errors at the end:
>>>>> grep: /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such file or
>>>>> directory
>>>>> sed: can't read /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such
>>>>> file or directory
>>>>>
>>>>> and include/standard-headers/asm-s390/virtio-ccw.h deletedch
>>>>>
>>>>> I would prefer having s390 people checking and testing that.  
>>>>
>>>> I think the kvm_virtio.h problem should be fixed by
>>>> http://patchwork.ozlabs.org/patch/838230/
>>>> which removes it from the set of headers the script imports.
>>>>
>>>> Cornelia/Christian -- any idea about the virtio-ccw.h issue ?
>>>>
>>>> thanks
>>>> -- PMM
>>>
>>> I had that commit queued for post-2.11, but I can also send it for 2.11.
>>>
>>> The virtio-ccw.h one looks weird... if I run the script on my s390-next
>>> branch against recent-ish Linux master, I just get the SPDX notice
>>> update for virtio-ccw.h.
>>>
>>
>> http://patchwork.ozlabs.org/patch/838230/ effectively fixes all issues:
>> - no errors anymore and
>> - no deletion of include/standard-headers/asm-s390/virtio-ccw.h anymore,
>> which is consistent with include/standard-headers/asm-s390/virtio-ccw.h.
>>
> 
> I assume the vITS code is post 2.11? If not, we can certainly submit 3 or 4 
> s390 patches (including 838230) for 2.11.

Yes my understanding was this was material for 2.12 as it depends on
v4.15. So I can wait for 838230 and I will re-post this series as a
PATCH then.

Peter, up to you if you are ready to consider taking the 2 first patches
for 2.11, as their dependencies are resolved and they actually would fix
everything along with v4.15 (since the vITS caches are voided on
individual GITS_BASER write). Only the end-user would have the error
report that full reset is not supported by the host kernel, as the reset
IOTCL is not used.

Thanks

Eric
> 

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

[Cornelia Huck]

On Thu, 23 Nov 2017 19:01:46 +0100
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> On 11/23/2017 06:44 PM, Auger Eric wrote:
> > Hi Cornelia, Peter,
> > 
> > On 23/11/17 18:14, Cornelia Huck wrote:  
> >> On Thu, 23 Nov 2017 17:01:32 +0000
> >> Peter Maydell <peter.maydell@linaro.org> wrote:
> >>  
> >>> On 23 November 2017 at 16:05, Auger Eric <eric.auger@redhat.com> wrote:  
> >>>> When using update-linux-headers.sh I get suspicious errors at the end:
> >>>> grep: /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such file or
> >>>> directory
> >>>> sed: can't read /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such
> >>>> file or directory
> >>>>
> >>>> and include/standard-headers/asm-s390/virtio-ccw.h deletedch
> >>>>
> >>>> I would prefer having s390 people checking and testing that.    
> >>>
> >>> I think the kvm_virtio.h problem should be fixed by
> >>> http://patchwork.ozlabs.org/patch/838230/
> >>> which removes it from the set of headers the script imports.
> >>>
> >>> Cornelia/Christian -- any idea about the virtio-ccw.h issue ?
> >>>
> >>> thanks
> >>> -- PMM  
> >>
> >> I had that commit queued for post-2.11, but I can also send it for 2.11.
> >>
> >> The virtio-ccw.h one looks weird... if I run the script on my s390-next
> >> branch against recent-ish Linux master, I just get the SPDX notice
> >> update for virtio-ccw.h.
> >>  
> > 
> > http://patchwork.ozlabs.org/patch/838230/ effectively fixes all issues:
> > - no errors anymore and
> > - no deletion of include/standard-headers/asm-s390/virtio-ccw.h anymore,
> > which is consistent with include/standard-headers/asm-s390/virtio-ccw.h.
> >   
> 
> I assume the vITS code is post 2.11? If not, we can certainly submit 3 or 4 
> s390 patches (including 838230) for 2.11.
> 

OTOH, we'll just have pain for any headers update until the first s390x
set for post 2.11 has been merged, so I'll send a pull request with
just that headers change.