From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752535AbdJFOit (ORCPT ); Fri, 6 Oct 2017 10:38:49 -0400 Received: from foss.arm.com ([217.140.101.70]:35084 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752468AbdJFOip (ORCPT ); Fri, 6 Oct 2017 10:38:45 -0400 Subject: Re: [PATCH v2 06/10] KVM: arm/arm64: vgic-its: Always attempt to save/restore device and collection tables To: Eric Auger , eric.auger.pro@gmail.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, marc.zyngier@arm.com, cdall@linaro.org, peter.maydell@linaro.org, wanghaibin.wang@huawei.com Cc: wu.wubin@huawei.com References: <1506518920-18571-1-git-send-email-eric.auger@redhat.com> <1506518920-18571-7-git-send-email-eric.auger@redhat.com> From: Andre Przywara Message-ID: <0b271294-1420-4d8f-fefa-9cfb656dfcc5@arm.com> Date: Fri, 6 Oct 2017 15:38:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1506518920-18571-7-git-send-email-eric.auger@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 27/09/17 14:28, Eric Auger wrote: > In case the device table save fails, we currently do not > attempt to save the collection table. However it may > happen that the device table fails because the structures > in memory are inconsistent with device GITS_BASER however > this does not mean collection backup can't be performed and > wouldn't succeed. Same on restore path. Without this patch, > after a reset and in case the device table fails in case of > L1 entry not valid, the guest gets stuck on restore. > > Signed-off-by: Eric Auger > > --- > > candidate to be CC'ed stable > --- > virt/kvm/arm/vgic/vgic-its.c | 11 +++-------- > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c > index 720552c..9e6b556 100644 > --- a/virt/kvm/arm/vgic/vgic-its.c > +++ b/virt/kvm/arm/vgic/vgic-its.c > @@ -2304,12 +2304,9 @@ static int vgic_its_save_tables_v0(struct vgic_its *its) > } > > ret = vgic_its_save_device_tables(its); > - if (ret) > - goto out; > > - ret = vgic_its_save_collection_table(its); > + ret |= vgic_its_save_collection_table(its); > > -out: > unlock_all_vcpus(kvm); > mutex_unlock(&its->its_lock); > mutex_unlock(&kvm->lock); > @@ -2336,11 +2333,9 @@ static int vgic_its_restore_tables_v0(struct vgic_its *its) > } > > ret = vgic_its_restore_collection_table(its); While the save functions above and this _v0 function here all use the standard C return semantics (==0 on success, failure otherwise), vgic_its_restore_collection_table() and the function call below can return 1 if successful, AFAICS. I don't think this handled correctly here? Cheers, Andre. > - if (ret) > - goto out; > > - ret = vgic_its_restore_device_tables(its); > -out: > + ret |= vgic_its_restore_device_tables(its); > + > unlock_all_vcpus(kvm); > mutex_unlock(&its->its_lock); > mutex_unlock(&kvm->lock); >