From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Fedin Subject: RE: [PATCH v2 2/5] KVM: arm64: Implement vGICv3 distributor and redistributor access from userspace Date: Fri, 04 Sep 2015 10:06:47 +0300 Message-ID: <012201d0e6e0$43de9db0$cb9bd910$@samsung.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Return-path: In-reply-to: Content-language: ru Sender: kvm-owner@vger.kernel.org To: 'Peter Maydell' Cc: kvmarm@lists.cs.columbia.edu, 'kvm-devel' , 'Marc Zyngier' , 'Andre Przywara' List-Id: kvmarm@lists.cs.columbia.edu Hello! > > + KVM_DEV_ARM_VGIC_GRP_REDIST_REGS > > + Attributes: > > + The attr field of kvm_device_attr encodes two values: > > + bits: | 63 | 62 .. 40 | 39 .. 32 | 31 .... 0 | > > + values: | size | reserved | cpu id | offset | > > We should avoid imposing an accidental limit on the maximum > number of CPUs in the userspace API. GICv3 doesn't have a > limit at 256 CPUs Ops, my fault, forgot. :( However, it seems to be very simple. "cpu id" is actually an index, not a real affinity ID (see http://lxr.free-electrons.com/source/include/linux/kvm_host.h#L427). Would it be OK just to enlarge KVM_DEV_ARM_VGIC_CPUID_MASK? bits: | 63 | 62 .. 32 | 31 .... 0 | values: | size | cpu id | offset | I think 31 bits is more than enough for CPU index. And, since id is actually an index, may be we should fix up docs? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia