From mboxrd@z Thu Jan 1 00:00:00 1970 From: Auger Eric Subject: Re: [PATCH v4 08/22] KVM: arm64: ITS: Implement vgic_mmio_uaccess_write_its_iidr Date: Mon, 10 Apr 2017 16:32:47 +0200 Message-ID: <5f1423fd-8f73-364a-9cf7-b4310957e2fd@redhat.com> References: <1490607072-21610-1-git-send-email-eric.auger@redhat.com> <1490607072-21610-9-git-send-email-eric.auger@redhat.com> <864lxzch9o.fsf@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: peter.maydell@linaro.org, drjones@redhat.com, kvm@vger.kernel.org, Prasun.Kapoor@cavium.com, vijayak@caviumnetworks.com, andre.przywara@arm.com, quintela@redhat.com, dgilbert@redhat.com, Vijaya.Kumar@cavium.com, linux-arm-kernel@lists.infradead.org, pbonzini@redhat.com, kvmarm@lists.cs.columbia.edu, christoffer.dall@linaro.org, eric.auger.pro@gmail.com To: Marc Zyngier Return-path: Received: from mx1.redhat.com ([209.132.183.28]:35186 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751812AbdDJOcy (ORCPT ); Mon, 10 Apr 2017 10:32:54 -0400 In-Reply-To: <864lxzch9o.fsf@arm.com> Sender: kvm-owner@vger.kernel.org List-ID: Hi Marc, On 08/04/2017 12:42, Marc Zyngier wrote: > On Mon, Mar 27 2017 at 10:30:58 AM, Eric Auger wrote: >> The GITS_IIDR revision field is used to encode the version of the >> table layout (ABI). So we need to restore it to check the table >> layout to be restored is compatible with the destination vITS. >> >> The user selected revision is stored in the user_revision field. >> It will be compared against the REV num at table restoration time. > > Why isn't it sufficient to keep it GITS_IIDR RO and let userspace find > out about the ABI revision that the kernel understands? > > Or are we planning on supporting multiple ABIs in the kernel? Yes as discussed with Peter, the plan is to allow several ABIs. So the userspace informs the destination about the ABI revision of the stored tables (contained by the GITS_IIDR). If the destination KVM does not support this ABI revision, table restore will fail. If so, do > we have a deprecation policy/plan? I don't mind either way, but it would > be good to document it... > > Maybe it is documented already and I missed it (which is perfectly > possible!). Well this is partly documented in Documentation/virtual/kvm/devices/arm-vgic-its.txt. No plan to deprecate. migration from KVM supporting v1 to KVM supporting V2 would be possible but not the contrary. Does it make sense? Thanks Eric > > Thanks, > > M. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: eric.auger@redhat.com (Auger Eric) Date: Mon, 10 Apr 2017 16:32:47 +0200 Subject: [PATCH v4 08/22] KVM: arm64: ITS: Implement vgic_mmio_uaccess_write_its_iidr In-Reply-To: <864lxzch9o.fsf@arm.com> References: <1490607072-21610-1-git-send-email-eric.auger@redhat.com> <1490607072-21610-9-git-send-email-eric.auger@redhat.com> <864lxzch9o.fsf@arm.com> Message-ID: <5f1423fd-8f73-364a-9cf7-b4310957e2fd@redhat.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Marc, On 08/04/2017 12:42, Marc Zyngier wrote: > On Mon, Mar 27 2017 at 10:30:58 AM, Eric Auger wrote: >> The GITS_IIDR revision field is used to encode the version of the >> table layout (ABI). So we need to restore it to check the table >> layout to be restored is compatible with the destination vITS. >> >> The user selected revision is stored in the user_revision field. >> It will be compared against the REV num at table restoration time. > > Why isn't it sufficient to keep it GITS_IIDR RO and let userspace find > out about the ABI revision that the kernel understands? > > Or are we planning on supporting multiple ABIs in the kernel? Yes as discussed with Peter, the plan is to allow several ABIs. So the userspace informs the destination about the ABI revision of the stored tables (contained by the GITS_IIDR). If the destination KVM does not support this ABI revision, table restore will fail. If so, do > we have a deprecation policy/plan? I don't mind either way, but it would > be good to document it... > > Maybe it is documented already and I missed it (which is perfectly > possible!). Well this is partly documented in Documentation/virtual/kvm/devices/arm-vgic-its.txt. No plan to deprecate. migration from KVM supporting v1 to KVM supporting V2 would be possible but not the contrary. Does it make sense? Thanks Eric > > Thanks, > > M. >