From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: [PATCH v3 5/5] KVM: arm64: Implement vGICv3 CPU interface access Date: Fri, 25 Sep 2015 23:27:44 +0100 Message-ID: <5605CA60.4080101@arm.com> References: <20be17e4e8aebcd7f1a52a634f449955bef99996.1441370053.git.p.fedin@samsung.com> <55E9B528.50106@arm.com> <16a001d0f6c1$b113cbd0$133b6370$@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "kvmarm@lists.cs.columbia.edu" , "kvm@vger.kernel.org" , Marc Zyngier , "'Peter Maydell'" To: Pavel Fedin Return-path: Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:39770 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751182AbbIYW2K (ORCPT ); Fri, 25 Sep 2015 18:28:10 -0400 In-Reply-To: <16a001d0f6c1$b113cbd0$133b6370$@samsung.com> Sender: kvm-owner@vger.kernel.org List-ID: On 24/09/15 13:08, Pavel Fedin wrote: > Hello! > >> The only thing that is pure 64-bit is the MRS/MSR _instruction_ in >> Aarch64, which always takes a x register. >> So can you model the register size according to the spec and allow >> 32-bit accesses from userland? > > I would like to complete the rework and respin v4, but this is, i guess, the only major issue left. > Additionally, it impacts the API. So... > In order to allow 32-bit accesses we would have to drop using ARM64_SYS_REG() for building > attribute ID and introduce something own, like KVM_DEV_ARM_VGIC_REG(). It will have different bits > layout (actually it will be missing 'arch' and 'size' field, and instead i will use > KVM_DEV_ARM_VGIC_64BIT flag for length specification, the same as for redistributor. > Will this be OK ? No, instead you should go with your original approach ;-) Thinking about that again I see that this interface is of course modeled after the architectured GICv3 system registers, where AArch32 has its own, separate encoding. So it's perfectly fine to use that 64-bit interface between userland and KVM now. If we later get Aarch32 support for the GICv3, we can add the appropriate Aarch32 sysregs to that interface and have a natural match. So: sorry for the noise, you can just go ahead with that native 64-bit sysregs encoding for [SG]ET_ONE_REG as you had before. Cheers, Andre.