From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752249AbdJFP3w (ORCPT ); Fri, 6 Oct 2017 11:29:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41316 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751489AbdJFP3v (ORCPT ); Fri, 6 Oct 2017 11:29:51 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 23EEB75738 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=eric.auger@redhat.com Subject: Re: [PATCH v2 06/10] KVM: arm/arm64: vgic-its: Always attempt to save/restore device and collection tables To: Andre Przywara , 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 References: <1506518920-18571-1-git-send-email-eric.auger@redhat.com> <1506518920-18571-7-git-send-email-eric.auger@redhat.com> <0b271294-1420-4d8f-fefa-9cfb656dfcc5@arm.com> Cc: wu.wubin@huawei.com From: Auger Eric Message-ID: <23010eed-f608-5d0e-3f82-ef07870fe80a@redhat.com> Date: Fri, 6 Oct 2017 17:29:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0b271294-1420-4d8f-fefa-9cfb656dfcc5@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 06 Oct 2017 15:29:51 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andre, On 06/10/2017 16:38, Andre Przywara wrote: > 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? After 01/10, vgic_its_restore_device_tables() can't return +1 anymore. However you're right vgic_its_restore_collection_table can restore + 1 if the collection table is completely filled and this is wrong. I will fix that. Thanks Eric > > 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); >>