From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55514) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8255-0002Ec-L9 for qemu-devel@nongnu.org; Thu, 25 Jun 2015 04:00:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z8250-0005Zx-Dd for qemu-devel@nongnu.org; Thu, 25 Jun 2015 04:00:19 -0400 Received: from mail-la0-f46.google.com ([209.85.215.46]:35172) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8250-0005Zi-2Q for qemu-devel@nongnu.org; Thu, 25 Jun 2015 04:00:14 -0400 Received: by lagi2 with SMTP id i2so39990178lag.2 for ; Thu, 25 Jun 2015 01:00:13 -0700 (PDT) Date: Thu, 25 Jun 2015 10:00:14 +0200 From: Christoffer Dall Message-ID: <20150625080014.GC28244@cbox> References: <5576C559.2000902@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] should KVM or userspace be the one which decides what MIPIDR/affinity values to assign to vcpus? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Marc Zyngier , Shlomo Pongratz , Shlomo Pongratz , Pavel Fedin , QEMU Developers , Shannon Zhao , Ashok Kumar , Igor Mammedov , "kvmarm@lists.cs.columbia.edu" Hi, [sorry for reviving this thread late] On Tue, Jun 09, 2015 at 12:24:13PM +0100, Peter Maydell wrote: > On 9 June 2015 at 11:52, Marc Zyngier wrote: > > On 08/06/15 11:52, Peter Maydell wrote: > >> On 8 June 2015 at 11:32, Igor Mammedov wrote: > >>> On Thu, 4 Jun 2015 18:17:39 +0100 > >>> Peter Maydell wrote: > >>>> On 4 June 2015 at 17:40, Shlomo Pongratz wrote: > >>>> In order for it to work correctly we must use MPIDR values in > >>>> the device tree which match the MPIDR values the kernel has picked > >>>> for the vcpus, so ask KVM what those values are. > >> > >>> Could we set QEMU's generated mpidr in kernel instead of pulling it from kernel, > >>> like we do with APIC ID in x86 and fix kernel not to reset it its own value > >>> (i.e. untie mpidr from vcpuid)? > >>> > >>> Then later we could move setting mpidr from kvm_arch_init_vcpu() into > >>> board code which should be setting it, since it knows/defines what topology it has. > >> > >> This is a question better asked on the kvmarm list (which I have cc'd), > >> because that is where the kernel folks hang out... > > > > Care to provide some context? Why is this required? > > The device tree spec says we have to tell the guest kernel the > affinity information for each CPU, in the reg field of the CPU node. > This device tree blob is created by userspace; the MPIDR the guest > actually reads is currently created by the kernel. The kernel's > vgic v3 code may also make assumptions about vcpu_id => affinity > mappings, I'm not sure. > > In current code: > * the kernel has an opinion about vcpu_id => MPIDR mappings > * QEMU does too, but it's not the same! > (luckily for 8 or fewer CPUs they agree, but this will not > do for GICv3 support) > > So either: > * QEMU needs to tell the kernel the MPIDR for each vCPU Does this option work for all configurations? What if you're running on a hardware with two clusters [8, 8] and QEMU asks KVM for a [12, 2] configuration, for example. Will it not be impossible for KVM to maintain correct semantics for coherency guarantees across what seems to the guest to be the same cluster, but really is two different clusters? Of course, KVM can deny an unsupported configuration, but I am wondering if we really think anybody will care about the 'model such specific hardware' aspect with KVM, or if we should only consider the 'I want a VM with x VCPUs' scenario, in which case the second option below seems simpler to me. Are there any concerns to think about wrt. migration here as well? Thanks, -Christoffer > * QEMU needs to ask the kernel the MPIDR for each vCPU > > Which is better? The latter is simpler and will work with > existing kernels. The former would let us (for instance) > use KVM when we're modelling (real world) boards which have > particular cluster configurations (which might not match the > kernel's current simplistic "always 16 CPUs at Aff0" setup). > > thanks > -- PMM > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm