search for: ttbr0

...+ b/xen/arch/arm/domain.c @@ -89,7 +89,11 @@ static void ctxt_switch_from(struct vcpu *p) /* MMU */ p->arch.vbar = READ_SYSREG(VBAR_EL1); +#ifdef CONFIG_ARM_32 p->arch.ttbcr = READ_SYSREG(TCR_EL1); +#else + p->arch.ttbcr = READ_SYSREG64(TCR_EL1); +#endif p->arch.ttbr0 = READ_SYSREG64(TTBR0_EL1); p->arch.ttbr1 = READ_SYSREG64(TTBR1_EL1); if ( is_pv32_domain(p->domain) ) @@ -168,7 +172,11 @@ static void ctxt_switch_to(struct vcpu *n) /* MMU */ WRITE_SYSREG(n->arch.vbar, VBAR_EL1); +#if defined(CONFIG_ARM_32) WRITE_SYSREG(n->a...

...t;> PAGE_SHIFT; si->flags = 0; - si->min_mfn = pstart >> PAGE_SHIFT; + //si->min_mfn = pstart >> PAGE_SHIFT; if (d->domain_id == 0) { si->flags = SIF_PRIVILEGED | SIF_INITDOMAIN; @@ -202,7 +202,7 @@ int domain_construct(struct domain *d, VCPU_REG(v, ttbr0) = (unsigned long)gpt; - mmu_switch_ttb(VCPU_REG(idle_vcpu[0], ttbr0)); + set_ttbr(VCPU_REG(idle_vcpu[0], ttbr0)); vcpu_context_init(v, 0, ventry, si); diff -r c6a412adfae7 xen/arch/arm/xen/tlb-v7.S --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xen/arch/arm/xen/tlb-v7.S Sun Feb 12 12:2...

This round implements all of the review comments from V2 and all patches are now acked. Unless there are any objections I intend to apply later this morning. Ian.

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

...bers more data than it should, if that's 32-bits then we get poor CodeGen. > and you probably want to expose support for 64-bit pointers anyway. It's a possibility, though no-one has asked for it yet. The biggest request we've actually had is for signed 32-bit pointers so that both TTBR0 and TTBR1 regions can be used. I could see a pretty strong argument for exposing unsigned pointers via a different address-space in that regime (for use in user_addr_t in kernel code), though you'd have to be pretty disciplined to make it work I think. > I'm not sure I follow the differ...

Hello, I am trying to boot Arndale board with Julien''s new XenARM patch series. But I have got "Data Abort" while in booting. My environment is: - Arndale Board - Xen-4.3-unstable from branch "arm" in git://xenbits.xen.org/people/julieng/xen-unstable.git - Dom0 Kernel from branch "dev-arndale-dom0-3.9" in

As you may have noticed, we released a 64b S4 chip that runs an ILP32 variant of the AArch64 ABI, and now we'd like to upstream that work. I've pushed preliminary patches to https://github.com/TNorthover/llvm-project/pull/1/commits (arm64_32 branch in that repo) to accompany this RFC. The changes divide fairly neatly into three categories. First, there's AArch64 ILP32 support, which

I''ve addressed all (I think/hope) of the review comments. The main change is to expose the guest virtual platform (e.g. memory layout and interrupt usage etc) to the toolstack via the public interface. This is then used during FDT generation. I have just codified the current defacto standard layout, it''s probably not the best layout but any change can be a separate patch/series.

...offsetof(struct vcpu_guest_context, dacr)); + DEFINE(OFFSET_VCPU_VBAR, offsetof(struct vcpu_guest_context, vbar)); + DEFINE(OFFSET_VCPU_CONTEXTIDR, offsetof(struct vcpu_guest_context, contextidr)); + DEFINE(OFFSET_VCPU_FCSEIDR, offsetof(struct vcpu_guest_context, fcseidr)); + DEFINE(OFFSET_VCPU_TTBR0, offsetof(struct vcpu_guest_context, ttbr0)); + DEFINE(OFFSET_VCPU_TTBR1, offsetof(struct vcpu_guest_context, ttbr1)); + DEFINE(OFFSET_VCPU_TTBCR, offsetof(struct vcpu_guest_context, ttbcr)); + //DEFINE(OFFSET_HYPERVISOR_CALLBACK, offsetof(struct vcpu_guest_context, event_callback)); + //DEFINE(...

Biggest change is to switch the new DTB node to /xen-core-devices instead of /xen at Stefano''s request. I also dropped the few patches title HACK etc which weren''t supposed to be there and fixed up some bits and pieces which folks commented on. George, WRT the freeze I think this is functionality which we cannot ship Xen 4.4 without. The impact is entirely constrained to the

Hi all, this small patch series implement guest SMP support for ARM, using the ARM PSCI interface for secondary cpu bringup. Stefano Stabellini (4): xen/arm: basic PSCI support, implement cpu_on xen/arm: support for guest SGI xen/arm: support vcpu_op hypercalls xen: move VCPUOP_register_vcpu_info to common code xen/arch/arm/domain.c | 66 ++++++++++++++++++++++++

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See