From: Auger Eric <eric.auger@redhat.com> To: Marc Zyngier <marc.zyngier@arm.com> 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, christoffer.dall@linaro.org, pbonzini@redhat.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, eric.auger.pro@gmail.com Subject: Re: [PATCH v4 08/22] KVM: arm64: ITS: Implement vgic_mmio_uaccess_write_its_iidr Date: Mon, 10 Apr 2017 17:17:11 +0200 [thread overview] Message-ID: <42ca421f-3c36-2f67-1e39-ec071cea3649@redhat.com> (raw) In-Reply-To: <74d62f62-c0eb-b7eb-4e3a-96b1b6d0d66d@arm.com> Hi Marc, On 10/04/2017 16:57, Marc Zyngier wrote: > On 10/04/17 15:32, Auger Eric wrote: >> Hi Marc, >> >> On 08/04/2017 12:42, Marc Zyngier wrote: >>> On Mon, Mar 27 2017 at 10:30:58 AM, Eric Auger <eric.auger@redhat.com> 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? > > Sort of. Say you have three systems: A and C, which only supports v1; B, > which supports v1 and v2. Let's say you migrate from A to B, and from B > to C. Is B mandated to be able to export the tables as v1 and v2? Or can > it restrict what it can export? At the moment migration from B to C will fail because source ABI rev = v2 > destination support ABI = v1. A (v1) -> B (v1 & v2): migration OK B (v1 & v2) -> C (v1): migration NOK What could be done if we want something clever is source KVM detects which ABI is sufficient and choose the lowest revision for the save. for instance if no vLPI choose rev1, otherwise rev2. rev2 typically is needed for vLPI support for nested as we need to save/restore vPE table and vLPIs in ITE (2x8 byte entries). The problem is that once you have migrated to B and you start playing with vLPIs and C do not know the table layout for vPE/vLPIs, you can't migrate anymore. Thanks Eric > > Thanks, > > M. >
WARNING: multiple messages have this Message-ID (diff)
From: eric.auger@redhat.com (Auger Eric) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v4 08/22] KVM: arm64: ITS: Implement vgic_mmio_uaccess_write_its_iidr Date: Mon, 10 Apr 2017 17:17:11 +0200 [thread overview] Message-ID: <42ca421f-3c36-2f67-1e39-ec071cea3649@redhat.com> (raw) In-Reply-To: <74d62f62-c0eb-b7eb-4e3a-96b1b6d0d66d@arm.com> Hi Marc, On 10/04/2017 16:57, Marc Zyngier wrote: > On 10/04/17 15:32, Auger Eric wrote: >> Hi Marc, >> >> On 08/04/2017 12:42, Marc Zyngier wrote: >>> On Mon, Mar 27 2017 at 10:30:58 AM, Eric Auger <eric.auger@redhat.com> 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? > > Sort of. Say you have three systems: A and C, which only supports v1; B, > which supports v1 and v2. Let's say you migrate from A to B, and from B > to C. Is B mandated to be able to export the tables as v1 and v2? Or can > it restrict what it can export? At the moment migration from B to C will fail because source ABI rev = v2 > destination support ABI = v1. A (v1) -> B (v1 & v2): migration OK B (v1 & v2) -> C (v1): migration NOK What could be done if we want something clever is source KVM detects which ABI is sufficient and choose the lowest revision for the save. for instance if no vLPI choose rev1, otherwise rev2. rev2 typically is needed for vLPI support for nested as we need to save/restore vPE table and vLPIs in ITE (2x8 byte entries). The problem is that once you have migrated to B and you start playing with vLPIs and C do not know the table layout for vPE/vLPIs, you can't migrate anymore. Thanks Eric > > Thanks, > > M. >
next prev parent reply other threads:[~2017-04-10 15:17 UTC|newest] Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-27 9:30 [PATCH v4 00/22] vITS save/restore Eric Auger 2017-03-27 9:30 ` Eric Auger 2017-03-27 9:30 ` [PATCH v4 01/22] KVM: arm/arm64: Add vITS save/restore API documentation Eric Auger 2017-03-27 9:30 ` Eric Auger 2017-04-08 10:03 ` Marc Zyngier 2017-04-08 10:03 ` Marc Zyngier 2017-04-08 13:15 ` Christoffer Dall 2017-04-08 13:15 ` Christoffer Dall 2017-04-08 17:31 ` Marc Zyngier 2017-04-08 17:31 ` Marc Zyngier 2017-04-10 10:18 ` Auger Eric 2017-04-10 10:18 ` Auger Eric 2017-04-10 10:42 ` Marc Zyngier 2017-04-10 10:42 ` Marc Zyngier 2017-04-08 18:17 ` Christoffer Dall 2017-04-08 18:17 ` Christoffer Dall 2017-04-10 14:26 ` Auger Eric 2017-04-10 14:26 ` Auger Eric 2017-04-21 9:12 ` Christoffer Dall 2017-04-21 9:12 ` Christoffer Dall 2017-03-27 9:30 ` [PATCH v4 02/22] KVM: arm/arm64: rename itte into ite Eric Auger 2017-03-27 9:30 ` Eric Auger 2017-04-08 10:04 ` Marc Zyngier 2017-04-08 10:04 ` Marc Zyngier 2017-03-27 9:30 ` [PATCH v4 03/22] arm/arm64: vgic: turn vgic_find_mmio_region into public Eric Auger 2017-03-27 9:30 ` Eric Auger 2017-04-08 10:06 ` Marc Zyngier 2017-04-08 10:06 ` Marc Zyngier 2017-04-08 10:06 ` Marc Zyngier 2017-03-27 9:30 ` [PATCH v4 04/22] KVM: arm64: ITS: KVM_DEV_ARM_VGIC_GRP_ITS_REGS group Eric Auger 2017-03-27 9:30 ` Eric Auger 2017-04-08 10:07 ` Marc Zyngier 2017-04-08 10:07 ` Marc Zyngier 2017-03-27 9:30 ` [PATCH v4 05/22] KVM: arm/arm64: vgic: expose (un)lock_all_vcpus Eric Auger 2017-03-27 9:30 ` Eric Auger 2017-04-08 10:09 ` Marc Zyngier 2017-04-08 10:09 ` Marc Zyngier 2017-03-27 9:30 ` [PATCH v4 06/22] KVM: arm64: ITS: Implement vgic_its_has_attr_regs and attr_regs_access Eric Auger 2017-03-27 9:30 ` Eric Auger 2017-04-08 10:24 ` Marc Zyngier 2017-04-08 10:24 ` Marc Zyngier 2017-04-08 10:24 ` Marc Zyngier 2017-03-27 9:30 ` [PATCH v4 07/22] KVM: arm64: ITS: Implement vgic_mmio_uaccess_write_its_creadr Eric Auger 2017-03-27 9:30 ` Eric Auger 2017-04-08 10:36 ` Marc Zyngier 2017-04-08 10:36 ` Marc Zyngier 2017-04-08 10:36 ` Marc Zyngier 2017-03-27 9:30 ` [PATCH v4 08/22] KVM: arm64: ITS: Implement vgic_mmio_uaccess_write_its_iidr Eric Auger 2017-03-27 9:30 ` Eric Auger 2017-04-08 10:42 ` Marc Zyngier 2017-04-08 10:42 ` Marc Zyngier 2017-04-08 10:42 ` Marc Zyngier 2017-04-10 14:32 ` Auger Eric 2017-04-10 14:32 ` Auger Eric 2017-04-10 14:57 ` Marc Zyngier 2017-04-10 14:57 ` Marc Zyngier 2017-04-10 15:07 ` Peter Maydell 2017-04-10 15:07 ` Peter Maydell 2017-04-10 15:17 ` Auger Eric [this message] 2017-04-10 15:17 ` Auger Eric 2017-04-11 10:05 ` Marc Zyngier 2017-04-11 10:05 ` Marc Zyngier 2017-04-11 10:08 ` Auger Eric 2017-04-11 10:08 ` Auger Eric 2017-04-11 10:16 ` Peter Maydell 2017-04-11 10:16 ` Peter Maydell 2017-04-11 10:29 ` Marc Zyngier 2017-04-11 10:29 ` Marc Zyngier 2017-04-11 10:43 ` Peter Maydell 2017-04-11 10:43 ` Peter Maydell 2017-04-11 10:56 ` Auger Eric 2017-04-11 10:56 ` Auger Eric 2017-03-27 9:30 ` [PATCH v4 09/22] KVM: arm64: ITS: Report the ITE size in GITS_TYPER Eric Auger 2017-03-27 9:30 ` Eric Auger 2017-04-08 17:42 ` Marc Zyngier 2017-04-08 17:42 ` Marc Zyngier 2017-03-27 9:31 ` [PATCH v4 10/22] KVM: arm64: ITS: Interpret MAPD Size field and check related errors Eric Auger 2017-03-27 9:31 ` Eric Auger 2017-04-08 17:59 ` Marc Zyngier 2017-04-08 17:59 ` Marc Zyngier 2017-04-08 17:59 ` Marc Zyngier 2017-03-27 9:31 ` [PATCH v4 11/22] KVM: arm64: ITS: Interpret MAPD ITT_addr field Eric Auger 2017-03-27 9:31 ` Eric Auger 2017-04-08 18:58 ` Marc Zyngier 2017-04-08 18:58 ` Marc Zyngier 2017-04-08 18:58 ` Marc Zyngier 2017-03-27 9:31 ` [PATCH v4 12/22] KVM: arm64: ITS: Check the device id matches TYPER DEVBITS range Eric Auger 2017-03-27 9:31 ` Eric Auger 2017-03-27 9:31 ` [PATCH v4 13/22] KVM: arm64: ITS: KVM_DEV_ARM_VGIC_GRP_ITS_TABLES group Eric Auger 2017-03-27 9:31 ` Eric Auger 2017-03-27 15:04 ` kbuild test robot 2017-03-27 15:04 ` kbuild test robot 2017-03-27 18:29 ` Auger Eric 2017-03-27 18:29 ` Auger Eric 2017-03-30 2:21 ` [kbuild-all] " Ye Xiaolong 2017-03-30 2:21 ` Ye Xiaolong 2017-03-30 6:46 ` Auger Eric 2017-03-30 6:46 ` Auger Eric 2017-03-30 7:29 ` Ye Xiaolong 2017-03-30 7:29 ` Ye Xiaolong 2017-03-30 8:29 ` Auger Eric 2017-03-30 8:29 ` Auger Eric 2017-04-09 10:09 ` Marc Zyngier 2017-04-09 10:09 ` Marc Zyngier 2017-03-27 9:31 ` [PATCH v4 14/22] KVM: arm64: ITS: vgic_its_alloc_ite/device Eric Auger 2017-03-27 9:31 ` Eric Auger 2017-04-09 10:13 ` Marc Zyngier 2017-04-09 10:13 ` Marc Zyngier 2017-03-27 9:31 ` [PATCH v4 15/22] KVM: arm64: ITS: Sort the device and ITE lists Eric Auger 2017-03-27 9:31 ` Eric Auger 2017-04-09 10:18 ` Marc Zyngier 2017-04-09 10:18 ` Marc Zyngier 2017-03-27 9:31 ` [PATCH v4 16/22] KVM: expose next_segment() Eric Auger 2017-03-27 9:31 ` Eric Auger 2017-03-27 9:31 ` [PATCH v4 17/22] KVM: arm64: ITS: Add infrastructure for table lookup Eric Auger 2017-03-27 9:31 ` Eric Auger 2017-04-09 10:36 ` Marc Zyngier 2017-04-09 10:36 ` Marc Zyngier 2017-03-27 9:31 ` [PATCH v4 18/22] KVM: arm64: ITS: Collection table save/restore Eric Auger 2017-03-27 9:31 ` Eric Auger 2017-04-10 9:55 ` Marc Zyngier 2017-04-10 9:55 ` Marc Zyngier 2017-04-11 9:57 ` Auger Eric 2017-04-11 9:57 ` Auger Eric 2017-04-11 10:03 ` Marc Zyngier 2017-04-11 10:03 ` Marc Zyngier 2017-03-27 9:31 ` [PATCH v4 19/22] KVM: arm64: ITS: vgic_its_check_id returns the entry's GPA Eric Auger 2017-03-27 9:31 ` Eric Auger 2017-03-27 9:31 ` [PATCH v4 20/22] KVM: arm64: ITS: ITT flush and restore Eric Auger 2017-03-27 9:31 ` Eric Auger 2017-04-10 12:39 ` Marc Zyngier 2017-04-10 12:39 ` Marc Zyngier 2017-04-11 10:19 ` Auger Eric 2017-04-11 10:19 ` Auger Eric 2017-03-27 9:31 ` [PATCH v4 21/22] KVM: arm64: ITS: Device table save/restore Eric Auger 2017-03-27 9:31 ` Eric Auger 2017-04-10 12:42 ` Marc Zyngier 2017-04-10 12:42 ` Marc Zyngier 2017-03-27 9:31 ` [PATCH v4 22/22] KVM: arm64: ITS: Pending " Eric Auger 2017-03-27 9:31 ` Eric Auger 2017-04-10 12:50 ` Marc Zyngier 2017-04-10 12:50 ` Marc Zyngier 2017-04-10 12:54 ` [PATCH v4 00/22] vITS save/restore Marc Zyngier 2017-04-10 12:54 ` Marc Zyngier
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=42ca421f-3c36-2f67-1e39-ec071cea3649@redhat.com \ --to=eric.auger@redhat.com \ --cc=Prasun.Kapoor@cavium.com \ --cc=Vijaya.Kumar@cavium.com \ --cc=andre.przywara@arm.com \ --cc=christoffer.dall@linaro.org \ --cc=dgilbert@redhat.com \ --cc=drjones@redhat.com \ --cc=eric.auger.pro@gmail.com \ --cc=kvm@vger.kernel.org \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=marc.zyngier@arm.com \ --cc=pbonzini@redhat.com \ --cc=peter.maydell@linaro.org \ --cc=quintela@redhat.com \ --cc=vijayak@caviumnetworks.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.