From: Marc Zyngier <marc.zyngier@arm.com> To: Auger Eric <eric.auger@redhat.com>, eric.auger.pro@gmail.com, christoffer.dall@linaro.org, vijayak@caviumnetworks.com, Vijaya.Kumar@cavium.com, peter.maydell@linaro.org, linux-arm-kernel@lists.infradead.org, drjones@redhat.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org Cc: andre.przywara@arm.com, Prasun.Kapoor@cavium.com, dgilbert@redhat.com, pbonzini@redhat.com Subject: Re: [RFC 07/13] KVM: arm64: ITS: Change entry_size and indirect bit in BASER Date: Fri, 13 Jan 2017 09:22:15 +0000 [thread overview] Message-ID: <7538fddf-919f-5428-a665-485ea1be6e9a@arm.com> (raw) In-Reply-To: <89752a29-d533-1f4c-9e9b-93e8bd0556b3@redhat.com> On 13/01/17 08:57, Auger Eric wrote: > Hi Marc, > > On 12/01/2017 18:05, Marc Zyngier wrote: >> On 12/01/17 15:56, Eric Auger wrote: >>> Change the device table entry_size to 16 bytes instead of 8. >>> We also Store the device and collection device in the its >>> struct. >>> >>> The patch also clears the indirect bit for the device BASER. >>> The indirect bit is set as read-only. >> >> Err... Why? We *really* want to continue supporting indirect tables, as >> this is a massive memory saver for the guest. >> >>> >>> Signed-off-by: Eric Auger <eric.auger@redhat.com> >>> >>> --- >>> >>> TODO: investigate support of 2 level tables, ie. enabling >>> Indirect = 1. Support of 2 level tables is implementation >>> defined. >> >> Clearly, that's a regression. What exactly is the issue that decided you >> to disable it? > Well no valuable reason besides I saw it was optional, lack of > time/knowledge and a bit of laziness. I will address this requirement in > my next respin. Ah, I was worried about something much more fundamental! ;-) > For my curiosity why did we choose not allowing the feature for > collections. Is that just because we think their number if going > sufficiently small compared to devices? Collections are usually a much smaller number (directly related to the number of CPUs in the system), and can be kept very compact. Devices, on the other hand, can be extremely sparse (to the point where a guest can fail to allocate enough memory to cover the required range). TBH, we could allow it for collections as well. It is just not that useful. Thanks, M. -- Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: marc.zyngier@arm.com (Marc Zyngier) To: linux-arm-kernel@lists.infradead.org Subject: [RFC 07/13] KVM: arm64: ITS: Change entry_size and indirect bit in BASER Date: Fri, 13 Jan 2017 09:22:15 +0000 [thread overview] Message-ID: <7538fddf-919f-5428-a665-485ea1be6e9a@arm.com> (raw) In-Reply-To: <89752a29-d533-1f4c-9e9b-93e8bd0556b3@redhat.com> On 13/01/17 08:57, Auger Eric wrote: > Hi Marc, > > On 12/01/2017 18:05, Marc Zyngier wrote: >> On 12/01/17 15:56, Eric Auger wrote: >>> Change the device table entry_size to 16 bytes instead of 8. >>> We also Store the device and collection device in the its >>> struct. >>> >>> The patch also clears the indirect bit for the device BASER. >>> The indirect bit is set as read-only. >> >> Err... Why? We *really* want to continue supporting indirect tables, as >> this is a massive memory saver for the guest. >> >>> >>> Signed-off-by: Eric Auger <eric.auger@redhat.com> >>> >>> --- >>> >>> TODO: investigate support of 2 level tables, ie. enabling >>> Indirect = 1. Support of 2 level tables is implementation >>> defined. >> >> Clearly, that's a regression. What exactly is the issue that decided you >> to disable it? > Well no valuable reason besides I saw it was optional, lack of > time/knowledge and a bit of laziness. I will address this requirement in > my next respin. Ah, I was worried about something much more fundamental! ;-) > For my curiosity why did we choose not allowing the feature for > collections. Is that just because we think their number if going > sufficiently small compared to devices? Collections are usually a much smaller number (directly related to the number of CPUs in the system), and can be kept very compact. Devices, on the other hand, can be extremely sparse (to the point where a guest can fail to allocate enough memory to cover the required range). TBH, we could allow it for collections as well. It is just not that useful. Thanks, M. -- Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2017-01-13 9:22 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-01-12 15:56 [RFC 00/13] vITS save/restore Eric Auger 2017-01-12 15:56 ` Eric Auger 2017-01-12 15:56 ` [RFC 01/13] KVM: arm/arm64: Add vITS save/restore API documentation Eric Auger 2017-01-12 16:52 ` Marc Zyngier 2017-01-12 16:52 ` Marc Zyngier 2017-01-13 9:07 ` Auger Eric 2017-01-13 9:07 ` Auger Eric 2017-01-13 9:46 ` Marc Zyngier 2017-01-13 9:46 ` Marc Zyngier 2017-01-30 16:15 ` Auger Eric 2017-01-30 16:15 ` Auger Eric 2017-02-03 14:00 ` Peter Maydell 2017-02-03 14:00 ` Peter Maydell 2017-02-03 14:51 ` Marc Zyngier 2017-02-03 14:51 ` Marc Zyngier 2017-01-12 15:56 ` [RFC 02/13] arm/arm64: vgic: turn vgic_find_mmio_region into public Eric Auger 2017-01-12 15:56 ` [RFC 03/13] KVM: arm64: ITS: KVM_DEV_ARM_VGIC_GRP_ITS_REGS group Eric Auger 2017-01-12 15:56 ` [RFC 04/13] KVM: arm64: ITS: Implement vgic_its_has_attr_regs and attr_regs_access Eric Auger 2017-01-12 15:56 ` [RFC 05/13] KVM: arm64: ITS: Implement vgic_mmio_uaccess_write_its_creadr Eric Auger 2017-01-12 15:56 ` [RFC 06/13] KVM: arm64: ITS: Expose ITT_Entry_Size in GITS_TYPER Eric Auger 2017-01-12 17:06 ` Andre Przywara 2017-01-12 17:06 ` Andre Przywara 2017-01-13 8:31 ` Auger Eric 2017-01-13 8:31 ` Auger Eric 2017-01-12 15:56 ` [RFC 07/13] KVM: arm64: ITS: Change entry_size and indirect bit in BASER Eric Auger 2017-01-12 17:05 ` Marc Zyngier 2017-01-12 17:05 ` Marc Zyngier 2017-01-13 8:57 ` Auger Eric 2017-01-13 8:57 ` Auger Eric 2017-01-13 9:22 ` Marc Zyngier [this message] 2017-01-13 9:22 ` Marc Zyngier 2017-01-12 15:56 ` [RFC 08/13] KVM: arm64: ITS: On MAPD interpret and store itt_addr and size Eric Auger 2017-01-12 15:56 ` [RFC 09/13] KVM: arm64: ITS: KVM_DEV_ARM_VGIC_GRP_ITS_TABLES group Eric Auger 2017-01-12 15:56 ` [RFC 10/13] KVM: arm64: ITS: vgic_its_alloc_itte/device Eric Auger 2017-01-12 15:56 ` [RFC 11/13] KVM: arm64: ITS: Collection table save/restore Eric Auger 2017-01-12 15:56 ` [RFC 12/13] KVM: arm64: ITS: Device and translation table flush Eric Auger 2017-01-12 15:56 ` [RFC 13/13] KVM: arm64: ITS: Pending table save/restore Eric Auger
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=7538fddf-919f-5428-a665-485ea1be6e9a@arm.com \ --to=marc.zyngier@arm.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=eric.auger@redhat.com \ --cc=kvm@vger.kernel.org \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=pbonzini@redhat.com \ --cc=peter.maydell@linaro.org \ --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.