Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] KVM: arm/arm64: vgic-its: Fix restoration of unmapped
 collections
To:     Marc Zyngier <maz@kernel.org>
Cc:     eric.auger.pro@gmail.com, linux-kernel@vger.kernel.org,
        kvmarm@lists.cs.columbia.edu
References: <20191213094237.19627-1-eric.auger@redhat.com>
 <2634d1361ac3d5518b3bea62dc40ab06@www.loen.fr>
From:   Auger Eric <eric.auger@redhat.com>
Message-ID: <9d84b239-3901-f995-765b-97b7574d0d74@redhat.com>
Date:   Fri, 13 Dec 2019 11:55:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <2634d1361ac3d5518b3bea62dc40ab06@www.loen.fr>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Marc,

On 12/13/19 11:43 AM, Marc Zyngier wrote:
> Hi Eric,
>=20
> On 2019-12-13 09:42, Eric Auger wrote:
>> Saving/restoring an unmapped collection is a valid scenario. For
>> example this happens if a MAPTI command was sent, featuring an
>> unmapped collection. At the moment the CTE fails to be restored.
>> Only compare against the number of online vcpus if the rdist
>> base is set.
>>
>> Cc: stable@vger.kernel.org # v4.11+
>> Fixes: ea1ad53e1e31a ("KVM: arm64: vgic-its: Collection table
>> save/restore")
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>> ---
>> =C2=A0virt/kvm/arm/vgic/vgic-its.c | 3 ++-
>> =C2=A01 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its=
.c
>> index 98c7360d9fb7..17920d1b350a 100644
>> --- a/virt/kvm/arm/vgic/vgic-its.c
>> +++ b/virt/kvm/arm/vgic/vgic-its.c
>> @@ -2475,7 +2475,8 @@ static int vgic_its_restore_cte(struct vgic_its
>> *its, gpa_t gpa, int esz)
>> =C2=A0=C2=A0=C2=A0=C2=A0 target_addr =3D (u32)(val >> KVM_ITS_CTE_RDBA=
SE_SHIFT);
>> =C2=A0=C2=A0=C2=A0=C2=A0 coll_id =3D val & KVM_ITS_CTE_ICID_MASK;
>>
>> -=C2=A0=C2=A0=C2=A0 if (target_addr >=3D atomic_read(&kvm->online_vcpu=
s))
>> +=C2=A0=C2=A0=C2=A0 if (target_addr !=3D COLLECTION_NOT_MAPPED &&
>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 target_addr >=3D atomic_re=
ad(&kvm->online_vcpus))
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return -EINVAL;
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0 collection =3D find_collection(its, coll_id);
>=20
> Looks good to me. Out of curiosity, how was this spotted?

I am currently writing some kvm-unit-tests to better test ITS and its
migration.

Thanks

Eric
>=20
> Thanks,
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 M.