From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: [PATCH 00/45] initial arm v8 (64-bit) support Date: Wed, 23 Jan 2013 15:56:16 +0000 Message-ID: <1358956576.17440.60.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel Cc: Tim Deegan , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org First off, Apologies for the massive patch series... This series boots a 32-bit dom0 kernel to a command prompt on an ARMv8 (AArch64) model. The kernel is the same one as I am currently using with the 32 bit hypervisor I haven't yet tried starting a guest or anything super advanced like that ;-). Also there is not real support for 64-bit domains at all, although in one or two places I have laid some groundwork. Sadly the 32- and 64-bit assembly is very different, which makes sharing the ASM bits pretty much impossible. (Other than register names, the big change is lack of general conditional instructions). AArch64 has removed the concept of co-processor registers and replaced it with system registers which are accessed by name (i.e. the assembler understands the names). There is most often a 1-1 mapping between an AArch64 system register and a AArch32 cp register. To try and reduce ifdeferry in common code I've introduced some macros which take the AArch64 name but which translate to the appropriate AArch32 cpreg access in the 32-bit hypervisor. A little bit of ifdeferry remains. Other uses of the coprocessors (e.g. cache/TLB flushing etc) are replaced with explicit instructions (again there's mostly a 1-1 mapping). We had already wrapped most of these in a suitable inline function so it was easy enough to abstract away. Lastly, rather than switch internally from explicitly sized types to unsigned long I have instead introduced some semantic types (register_t and vaddr_t, which complement the existing paddr_t). I'm not really too sure of this approach though. Ian.