From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH] xen/arm: Implement MPIDR per VCPU Date: Thu, 13 Jun 2013 10:46:08 +0100 Message-ID: <51B994E0.303@linaro.org> References: <1370605083-15747-1-git-send-email-julien.grall@linaro.org> <1371049906.24512.455.camel@zakaz.uk.xensource.com> <1371111577.24512.469.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1371111577.24512.469.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Patch Tracking , stefano.stabellini@citrix.com, "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 06/13/2013 09:19 AM, Ian Campbell wrote: > On Wed, 2013-06-12 at 23:23 +0100, Julien Grall wrote: >> On 06/12/2013 04:11 PM, Ian Campbell wrote: >> >>> On Fri, 2013-06-07 at 12:38 +0100, Julien Grall wrote: >>>> Use different affinity for each VCPU and always expose an SMP systems to >>>> the guest. >>>> >>>> Signed-off-by: Julien Grall >>>> --- >>>> xen/arch/arm/domain.c | 11 +++++++++-- >>>> xen/include/asm-arm/processor.h | 6 ++++++ >>>> 2 files changed, 15 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c >>>> index ff1410d..4654c9b 100644 >>>> --- a/xen/arch/arm/domain.c >>>> +++ b/xen/arch/arm/domain.c >>>> @@ -150,7 +150,8 @@ static void ctxt_switch_to(struct vcpu *n) >>>> isb(); >>>> >>>> WRITE_SYSREG32(n->domain->arch.vpidr, VPIDR_EL2); >>>> - WRITE_SYSREG(n->domain->arch.vmpidr, VMPIDR_EL2); >>>> + WRITE_SYSREG(n->domain->arch.vmpidr | (n->vcpu_id << MPIDR_AFF0_SHIFT), >>>> + VMPIDR_EL2); >>> >>> Perhaps we should add v->arch.vmpidr and use that instead? >> >> As it's a read-only register, why can't we recreate it at each context >> switch? > > Just to avoid unnecessary calculations on the context switch path. It's > two memory accesses, a shift and an or rather than just one memory > access. Maybe that's lost in the noise though. > >> Adding a new field per cpu is a waste of space mainly when the >> vcpu structure must not be greater than a page. > > How close are we to this? The current size of each vcpu structure are: - arm32 : 2304 bytes - arm64 : 3328 bytes > >> >>>> /* VGIC */ >>>> gic_restore_state(n); >>>> @@ -495,7 +496,13 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags) >>>> >>>> /* Default the virtual ID to match the physical */ >>>> d->arch.vpidr = boot_cpu_data.midr.bits; >>>> - d->arch.vmpidr = boot_cpu_data.mpidr.bits; >>>> + /* >>>> + * Expose an SMP systems and remove the AFF0. It will be replace by >>>> + * the VPCU ID >>> >>> I wonder if that instead of basing this on the underlying processor we >>> should fabricate an entirely virtual one? >> >> Hum .. right, AFF1 could be different to 0. >> Is it okay if xen exposes all the vcpus in the same cluster? > > When Xen becomes multicluster aware then we will have to rethink but I > think all vcpus in the same cluster is the correct thing to do for the > time being. I will rewrite the patch with a virtual MPIDR. -- Julien