search for: sctlr

This patch fixes size of ttbcr register (TCR_EL1 in case of AArch64) and it''s programming considering size in case of context switch. Currently ttbcr is defined as 32b register but for AArch64 TCR_EL1 size is 64b. Signed-off-by: Anup Patel <anup.patel@linaro.org> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org> --- xen/arch/arm/domain.c | 8

Hi Ian, I try compile the bootwrapper for cubieboard2 like this: joshzhao@joshzhao-ThinkCentre-M58p:~/project/Xen/A20/boot-wrapper$ make cubieboard2_defconfig CROSS_COMPILE=arm-linux-gnueabihf- # # configuration written to .config # joshzhao@joshzhao-ThinkCentre-M58p:~/project/Xen/A20/boot-wrapper$ make CROSS_COMPILE=arm-linux-gnueabihf- make -C scripts/kconfig -f Makefile.bootwrapper

Hi, I experienced a crash in code compiled with Clang 10.0.0 due to a misaligned 64-bit data access. The (ARMv8) CPU is configured with SCTL.A == 1 (alignment check enable). With SCTLR.A == 0 the code runs as expected. After some investigation I came up with the following reproducer: ---8<-------8<-------8<-------8<-------8<-------8<-------8<------- $ cat test.c extern char *g; int memcmp(const void *s1, const void *s2, unsigned long n); int f(void *c) {...

...>> ARMSubtarget to accurately represent this table. I would propose that >> we keep the existing field for unaligned access and add a new field for > element-aligned access. >> >> The AllowsUnAlignedMem field remains as is and it could be used to >> represent the SCTLR.A column in Table A3-1. The >> AllowsElementAlignedNEON field would be used allow targets to generate >> vld1/vst1 instructions for element-aligned accesses. By default it would > be set to true for armv7 targets with NEON. > > That doesn't make sense to me. Element-ali...

...represent this table. I would propose that > >> we keep the existing field for unaligned access and add a new field > >> for > > element-aligned access. > >> > >> The AllowsUnAlignedMem field remains as is and it could be used to > >> represent the SCTLR.A column in Table A3-1. The > >> AllowsElementAlignedNEON field would be used allow targets to > >> generate > >> vld1/vst1 instructions for element-aligned accesses. By default it > >> would > > be set to true for armv7 targets with NEON. > > > &g...

...the correct code setup in ARMSubtarget to > accurately represent this table. I would propose that we keep the existing > field for unaligned access and add a new field for element-aligned access. > > The AllowsUnAlignedMem field remains as is and it could be used to represent > the SCTLR.A column in Table A3-1. The AllowsElementAlignedNEON field would > be used allow targets to generate vld1/vst1 instructions for element-aligned > accesses. By default it would be set to true for armv7 targets with NEON. That doesn't make sense to me. Element-aligned Neon load/stores are...

...e correct code setup in > ARMSubtarget to accurately represent this table. I would propose that > we keep the existing field for unaligned access and add a new field for element-aligned access. > > The AllowsUnAlignedMem field remains as is and it could be used to > represent the SCTLR.A column in Table A3-1. The > AllowsElementAlignedNEON field would be used allow targets to generate > vld1/vst1 instructions for element-aligned accesses. By default it would be set to true for armv7 targets with NEON. That doesn't make sense to me. Element-aligned Neon load/stores a...

...ow I do not think we have the correct code setup in ARMSubtarget to accurately represent this table. I would propose that we keep the existing field for unaligned access and add a new field for element-aligned access. The AllowsUnAlignedMem field remains as is and it could be used to represent the SCTLR.A column in Table A3-1. The AllowsElementAlignedNEON field would be used allow targets to generate vld1/vst1 instructions for element-aligned accesses. By default it would be set to true for armv7 targets with NEON. The -arm-strict-align would set both of the fields to false. This would retain the...

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

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.

...++- 3 files changed, 10 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 1e9776d..aa0f191 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -331,7 +331,7 @@ int construct_dom0(struct domain *d) WRITE_CP32(SCTLR_BASE, SCTLR); - WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM, HCR); + WRITE_CP32(HCR_PTW|HCR_BSU_OUTER|HCR_AMO|HCR_IMO|HCR_VM|HCR_TWI, HCR); isb(); local_abort_enable(); diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 5347dce..c3e6404 100644 --- a/xen/a...

Hello, Thanks again. We did try overestimating the alignment, and saw the vldr you reference here. It looks like a recent change (r161962?) did enable vld1 generation for this case (great!) on darwin, but not linux. I'm not sure if the effect of lowering load <4 x i16>* align 2 to vld1.16 this was intentional in this change or not. If so, my question is what is the preferable way to

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.

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

...e.org <op-tee at lists.trustedfirmware.org> Subject: [llvm-dev] Aarch64: unaligned access despite -mstrict-align Hi, I experienced a crash in code compiled with Clang 10.0.0 due to a misaligned 64-bit data access. The (ARMv8) CPU is configured with SCTL.A == 1 (alignment check enable). With SCTLR.A == 0 the code runs as expected. After some investigation I came up with the following reproducer: ---8<-------8<-------8<-------8<-------8<-------8<-------8<------- $ cat test.c extern char *g; int memcmp(const void *s1, const void *s2, unsigned long n); int f(void *c) {...

...rm32(struct xc_dom_image *dom, void *ptr) * like a valid pointer to a set of ATAGS or a DTB. */ ctxt->user_regs.r2_usr = dom->devicetree_blob ? - dom->devicetree_seg.vstart : 0xffffffff; + (dom->devicetree_seg.vstart - offset) : 0xffffffff; ctxt->sctlr = SCTLR_GUEST_INIT; @@ -280,15 +282,15 @@ int arch_setup_meminit(struct xc_dom_image *dom) if ( dom->devicetree_blob ) { - const uint64_t rambase = dom->rambase_pfn << XC_PAGE_SHIFT; - const uint64_t ramend = rambase + ( dom->total_pages << XC_PAGE_S...

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

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

I''m afraid this series is rather a grab bag and it is distressingly large at this stage. With this series I can boot an Xgene board until it fails to find its SATA controller. This is a dom0 issue for which patches are pending from APM (/me nudges Anup). As well as the APM specific platform stuff there are also some generic improvements which were either necessary or useful during this