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

Re: [Xen-devel] [PATCH v3 08/11] xen: arm: rewrite start of day page table and cpu bring up



On Fri, 2013-09-27 at 13:30 +0100, Julien Grall wrote:
> On 09/27/2013 11:20 AM, Ian Campbell wrote:
> > This is unfortunately a rather large monolithic patch.
> > 
> > Rather than bringing up all CPUs in lockstep as we setup paging and relocate
> > Xen instead create a simplified set of dedicated boot time pagetables.
> > 
> > This allows secondary CPUs to remain powered down or in the firmware until 
> > we
> > actually want to enable them. The bringup is now done later on in C and can 
> > be
> > driven by DT etc. I have included code for the vexpress platform, but other
> > platforms will need to be added.
> > 
> > The mechanism for deciding how to bring up a CPU differs between arm32 and
> > arm64. On arm32 it is essentially a per-platform property, with the 
> > exception
> > of PSCI which can be implemented globally (but isn't here). On arm64 there 
> > is a
> > per-cpu property in the device tree.
> > 
> > Secondary CPUs are brought up directly into the relocated Xen image, 
> > instead of
> > relying on being able to launch on the unrelocated Xen and hoping that it
> > hasn't been clobbered.
> > 
> > As part of this change drop support for switching from secure mode to NS 
> > HYP as
> > well as the early CPU kick. Xen now requires that it is launched in NS HYP
> > mode and that firmware configure things such that secondary CPUs can be 
> > woken
> > up by a primarly CPU in HYP mode. This may require fixes to bootloaders or 
> > the
> > use of a boot wrapper.
> > 
> > The changes done here (re)exposed an issue with relocating Xen and the 
> > compiler
> > spilling values to the stack between the copy and the actual switch to the
> > relocaed copy of Xen in setup_pagetables. Therefore switch to doing the copy
> > and switch in a single asm function where we can control precisely what gets
> > spilled to the stack etc.
> > 
> > Since we now have a separate set of boot pagetables it is much easier to 
> > build
> > the real Xen pagetables inplace before relocating rather than the more 
> > complex
> > approach of rewriting the pagetables in the relocated copy before switching.
> > 
> > This will also enable Xen to be loaded above the 4GB boundary on 64-bit.
> 
> There is a conflict with this patch and your recently pushed patch
> series "xen: arm: memory mangement fixes / improvements".

Thanks, I thought I'd rebased after pushing that but obviously not.

I'll rebase, if it's not too much surgery I won't both reposting.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.