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(-)
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
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
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 >
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
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.
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
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.
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 >
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.
© 2016 - 2024 Red Hat, Inc.