qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] MPIDR Aff0 question


From: Marc Zyngier
Subject: Re: [Qemu-arm] MPIDR Aff0 question
Date: Thu, 4 Feb 2016 18:51:06 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

Hi Drew,

On 04/02/16 18:38, Andrew Jones wrote:
> 
> Hi Marc and Andre,
> 
> I completely understand why reset_mpidr() limits Aff0 to 16, thanks
> to Andre's nice comment about ICC_SGIxR. Now, here's my question;
> it seems that the Cortex-A{53,57,72} manuals want to further limit
> Aff0 to 4, going so far as to say bits 7:2 are RES0. I'm looking
> at userspace dictating the MPIDR for KVM. QEMU tries to model the
> A57 right now, so to be true to the manual, Aff0 should only address
> four PEs, but that would generate a higher trap cost for SGI broadcasts
> when using KVM. Sigh... what to do?

There are two things to consider:

- The GICv3 architecture is perfectly happy to address 16 CPUs at Aff0.
- ARM cores are designed to be grouped in clusters of at most 4, but
other implementations may have very different layouts.

If you want to model something matches reality, then you have to follow
what Cortex-A cores do, assuming you are exposing Cortex-A cores. But
absolutely nothing forces you to (after all, we're not exposing the
intricacies of L2 caches, which is the actual reason why we have
clusters of 4 cores).

> Additionally I'm looking at adding support to represent more complex
> topologies in the guest MPIDR (sockets/cores/threads). I see Linux
> currently expects Aff2:socket, Aff1:core, Aff0:thread when threads
> are in use, and Aff1:socket, Aff0:core, when they're not. Assuming
> there are never more than 4 threads to a core makes the first
> expectation fine, but the second one would easily blow the 2 Aff0
> bits alloted, and maybe even a 4 Aff0 bit allotment.
> 
> So my current thinking is that always using Aff2:socket, Aff1:cluster,
> Aff0:core (no threads allowed) would be nice for KVM, and allowing up
> to 16 cores to be addressed in Aff0. As it seems there's no standard
> for MPIDR, then that could be the KVM guest "standard".
> 
> TCG note: I suppose threads could be allowed there, using
> Aff2:socket, Aff1:core, Aff0:thread (no more than 4 threads)

I'm not sure why you'd want to map a given topology to a guest (other
than to give the illusion of a particular system). The affinity register
does not define any of this (as you noticed). And what would Aff3 be in
your design? Shelve? Rack? ;-)

What would the benefit of defining a "socket"?

Thanks,

        M.
-- 
Jazz is not dead. It just smells funny...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]