From: Andre Przywara <andre.przywara@arm.com> To: Christoffer Dall <christoffer.dall@linaro.org>, Tomasz Nowicki <tn@semihalf.com> Cc: marc.zyngier@arm.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation Date: Mon, 14 Mar 2016 11:13:14 +0000 [thread overview] Message-ID: <56E69CCA.5070407@arm.com> (raw) In-Reply-To: <20160313181608.GA15988@cbox> Hi, On 13/03/16 18:16, Christoffer Dall wrote: > On Wed, Mar 09, 2016 at 12:35:26PM +0100, Tomasz Nowicki wrote: >> Hi Andre, >> >> Forgive me if anybody already asked this question for previous >> series versions. >> >> The review is still pending so it is worth to ask. What is your idea >> for saving and restoring vITS state? I notice device, itte and >> collection linked lists which are essential for vITS state. Of >> course it is not feasible to transfer these list to e.g. QEMU using >> KVM_{GET|SET}_DEVICE_ATTR. >> > If I recall correctly these items are the ones stored in memory on real > hardware, and not in hardware registers. Potentially, but not necessarily. > We had an idea where userspace asks the kernel vgic to flush its > internal cache into the memory allocated by the guest driver for the > vITS data structures and then the state would be transferred across to > the new VM via the memory transfer mechanism. The problem with this idea is that we currently don't use guest memory to hold those data structures. As we report 0 on reads for all BASER<n> registers, this includes Type=0 for each register, which translates into "Unimplemented", so a guest OS would never allocate memory for it. Instead we claim to hold all information in our "cache" (aka. host memory). This has several advantages, but obviously breaks this save/restore approach. So I see two ways to fix this: 1.) we find a KVM specific way of letting userland save and restore the ITS tables directly 2.) we implement the BASER<n> registers, but still use our "cache" for normal operations. On demand we would serialize KVM's virtual ITS data structures and put them into the guest's memory, so they could be saved/restored from there. > Only caveat there I think was that we had to decide on a storage format > in those memory regions, to allow QEMU to understand the state and to > ensure back/forwards compatibility between KVM versions. Do we need QEMU to actually understand this? Can't we just leave this all to the kernel and QEMU just passes on the data? That would still require some ABI stability between kernel versions in this respect, but it's less problematic than exposing the data format to userland at all. Cheers, Andre.
WARNING: multiple messages have this Message-ID (diff)
From: andre.przywara@arm.com (Andre Przywara) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation Date: Mon, 14 Mar 2016 11:13:14 +0000 [thread overview] Message-ID: <56E69CCA.5070407@arm.com> (raw) In-Reply-To: <20160313181608.GA15988@cbox> Hi, On 13/03/16 18:16, Christoffer Dall wrote: > On Wed, Mar 09, 2016 at 12:35:26PM +0100, Tomasz Nowicki wrote: >> Hi Andre, >> >> Forgive me if anybody already asked this question for previous >> series versions. >> >> The review is still pending so it is worth to ask. What is your idea >> for saving and restoring vITS state? I notice device, itte and >> collection linked lists which are essential for vITS state. Of >> course it is not feasible to transfer these list to e.g. QEMU using >> KVM_{GET|SET}_DEVICE_ATTR. >> > If I recall correctly these items are the ones stored in memory on real > hardware, and not in hardware registers. Potentially, but not necessarily. > We had an idea where userspace asks the kernel vgic to flush its > internal cache into the memory allocated by the guest driver for the > vITS data structures and then the state would be transferred across to > the new VM via the memory transfer mechanism. The problem with this idea is that we currently don't use guest memory to hold those data structures. As we report 0 on reads for all BASER<n> registers, this includes Type=0 for each register, which translates into "Unimplemented", so a guest OS would never allocate memory for it. Instead we claim to hold all information in our "cache" (aka. host memory). This has several advantages, but obviously breaks this save/restore approach. So I see two ways to fix this: 1.) we find a KVM specific way of letting userland save and restore the ITS tables directly 2.) we implement the BASER<n> registers, but still use our "cache" for normal operations. On demand we would serialize KVM's virtual ITS data structures and put them into the guest's memory, so they could be saved/restored from there. > Only caveat there I think was that we had to decide on a storage format > in those memory regions, to allow QEMU to understand the state and to > ensure back/forwards compatibility between KVM versions. Do we need QEMU to actually understand this? Can't we just leave this all to the kernel and QEMU just passes on the data? That would still require some ABI stability between kernel versions in this respect, but it's less problematic than exposing the data format to userland at all. Cheers, Andre.
next prev parent reply other threads:[~2016-03-14 11:13 UTC|newest] Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-10-07 14:55 [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-07 14:55 ` [PATCH v3 01/16] KVM: arm/arm64: VGIC: don't track used LRs in the distributor Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-07 14:55 ` [PATCH v3 02/16] KVM: arm/arm64: remove now unused code after stay-in-LR rework Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-07 14:55 ` [PATCH v3 03/16] KVM: extend struct kvm_msi to hold a 32-bit device ID Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-07 14:55 ` [PATCH v3 04/16] KVM: arm/arm64: add emulation model specific destroy function Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-07 14:55 ` [PATCH v3 05/16] KVM: arm/arm64: extend arch CAP checks to allow per-VM capabilities Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-07 14:55 ` [PATCH v3 06/16] KVM: arm/arm64: make GIC frame address initialization model specific Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-07 14:55 ` [PATCH v3 07/16] KVM: arm64: Introduce new MMIO region for the ITS base address Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-07 14:55 ` [PATCH v3 08/16] KVM: arm64: handle ITS related GICv3 redistributor registers Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-22 15:46 ` Pavel Fedin 2015-10-22 15:46 ` Pavel Fedin 2015-10-22 15:55 ` Pavel Fedin 2015-10-22 15:55 ` Pavel Fedin 2015-10-07 14:55 ` [PATCH v3 09/16] KVM: arm64: introduce ITS emulation file with stub functions Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-07 14:55 ` [PATCH v3 10/16] KVM: arm64: implement basic ITS register handlers Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-07 14:55 ` [PATCH v3 11/16] KVM: arm64: add data structures to model ITS interrupt translation Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-07 14:55 ` [PATCH v3 12/16] KVM: arm64: handle pending bit for LPIs in ITS emulation Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-07 15:10 ` Pavel Fedin 2015-10-07 15:10 ` Pavel Fedin 2015-10-07 15:35 ` Marc Zyngier 2015-10-07 15:35 ` Marc Zyngier 2015-10-07 15:46 ` Pavel Fedin 2015-10-07 15:46 ` Pavel Fedin 2015-10-07 15:49 ` Marc Zyngier 2015-10-07 15:49 ` Marc Zyngier 2015-10-12 7:40 ` Pavel Fedin 2015-10-12 7:40 ` Pavel Fedin 2015-10-12 11:39 ` Pavel Fedin 2015-10-12 11:39 ` Pavel Fedin 2015-10-12 14:17 ` Andre Przywara 2015-10-12 14:17 ` Andre Przywara 2015-10-07 14:55 ` [PATCH v3 13/16] KVM: arm64: sync LPI configuration and pending tables Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-21 11:29 ` Pavel Fedin 2015-10-21 11:29 ` Pavel Fedin 2015-10-07 14:55 ` [PATCH v3 14/16] KVM: arm64: implement ITS command queue command handlers Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-14 12:26 ` Pavel Fedin 2015-10-14 12:26 ` Pavel Fedin 2015-10-07 14:55 ` [PATCH v3 15/16] KVM: arm64: implement MSI injection in ITS emulation Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-11-25 13:28 ` Pavel Fedin 2015-11-25 13:28 ` Pavel Fedin 2015-10-07 14:55 ` [PATCH v3 16/16] KVM: arm64: enable ITS emulation as a virtual MSI controller Andre Przywara 2015-10-07 14:55 ` Andre Przywara 2015-10-07 16:05 ` [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation Pavel Fedin 2015-10-07 16:05 ` Pavel Fedin 2015-10-07 16:22 ` Marc Zyngier 2015-10-07 16:22 ` Marc Zyngier 2015-10-07 18:09 ` Pavel Fedin 2015-10-07 18:09 ` Pavel Fedin 2015-10-07 19:48 ` Marc Zyngier 2015-10-07 19:48 ` Marc Zyngier 2015-10-07 19:48 ` Marc Zyngier 2015-10-08 8:41 ` Pavel Fedin 2015-10-08 8:41 ` Pavel Fedin 2015-10-10 15:37 ` Christoffer Dall 2015-10-10 15:37 ` Christoffer Dall 2015-10-12 14:12 ` Andre Przywara 2015-10-12 14:12 ` Andre Przywara 2015-10-12 15:18 ` Pavel Fedin 2015-10-12 15:18 ` Pavel Fedin 2015-10-14 8:48 ` Eric Auger 2015-10-14 8:48 ` Eric Auger 2015-10-14 8:50 ` Pavel Fedin 2015-10-14 8:50 ` Pavel Fedin 2015-10-13 15:46 ` Pavel Fedin 2015-10-13 15:46 ` Pavel Fedin 2016-03-09 11:35 ` Tomasz Nowicki 2016-03-09 11:35 ` Tomasz Nowicki 2016-03-13 18:16 ` Christoffer Dall 2016-03-13 18:16 ` Christoffer Dall 2016-03-14 11:13 ` Andre Przywara [this message] 2016-03-14 11:13 ` Andre Przywara 2016-03-14 17:29 ` Peter Maydell 2016-03-14 17:29 ` Peter Maydell 2016-03-14 17:54 ` Marc Zyngier 2016-03-14 17:54 ` Marc Zyngier 2016-03-14 18:20 ` Andre Przywara 2016-03-14 18:20 ` Andre Przywara 2016-03-14 18:36 ` Marc Zyngier 2016-03-14 18:36 ` Marc Zyngier 2016-03-18 9:40 ` Christoffer Dall 2016-03-18 9:40 ` Christoffer Dall 2016-03-18 17:14 ` Peter Maydell 2016-03-18 17:14 ` Peter Maydell 2016-03-18 9:38 ` Christoffer Dall 2016-03-18 9:38 ` Christoffer Dall
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=56E69CCA.5070407@arm.com \ --to=andre.przywara@arm.com \ --cc=christoffer.dall@linaro.org \ --cc=kvm@vger.kernel.org \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=marc.zyngier@arm.com \ --cc=tn@semihalf.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.