similar to: [PATCH v2 0/2] Implement VFP context switch for arm32

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

On 9/17/2015 7:04 AM, Sky Flyer via llvm-dev wrote: > It seems like d0 is always 14! > I check it with ARMGenAsmMatcher.inc it was the same! > How is it possible? because it should give the same register value that > matches the underlying platform not any autogenerated value!? The returned number is the register id as defined in <YourTarget>GenRegisterInfo.inc. These numbers

Dear all, in my TestRegisterInfo.td file, I defined a register like this: class TestReg<bits<6> enc, string name> : Register<name> { let HWEncoding{5-0} = enc; let Namespace = "TEST"; } def D0 : TestReg<0x01, "d0">, DwarfRegNum<[1]>; but when I compile, the result I have in TestGenAsmMatcher.inc is this: case 'd': // 7

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

We currently setup page table walks etc as outer-shareable. Given we don''t really make the distinction between inner- and outer-shareable yet err on theside of safety. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> Cc: Tim Deegan <tim@xen.org> --- xen/include/asm-arm/flushtlb.h | 4 ++-- 1 files

This patch series implements SMP boot for arch/arm, as far as getting all CPUs up and running the idle loop. Changes from v1: - moved barriers out of loop in udelay() - dropped broken GIC change in favour of explanatory comment - made the increment of ready_cpus atomic (I couldn''t move the increment to before signalling the next CPU because the PT switch has to happen between

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, I have been gone for a while, finishing work on my Master's thesis... Now that I'm back I updated LLVM to the most recent version and found that my FP_ABS SelectionDAGNode type and code generation was now conflicting with the new FABS node type. I brought the rest of my local modifications in line with the FABS implementation, so here is my patch that includes sqrt, sin and cos

> ~/Desktop/Sanjeev/LLVM/llvm-2.7/Release/lib/libLLVMgold.so --eh-frame-hdr > -melf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o Ok, this way you're generating code for x86 > /usr/lib/crti.o > /usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0/crtbegin.o > -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0  -L/usr/local/lib -lgcc > --as-needed -lgcc_s --no-as-needed -lc -lgcc

Sorry for not explaining well. After compiling with g++-cross g++-cross -c a.c I do link using this command /gold_binutils/build/gold/ld-new -plugin ~/Desktop/Sanjeev/LLVM/llvm-2.7/Release/lib/libLLVMgold.so --eh-frame-hdr -melf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc/i686-pc-linux-gnu/4.2.0/crtbegin.o

Trap guest WFI, block the guest VCPU unless it has pending interrupts. Awake the guest vcpu when a new interrupt for it arrrives. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- xen/arch/arm/domain_build.c | 2 +- xen/arch/arm/traps.c | 6 ++++++ xen/arch/arm/vgic.c | 4 +++- 3 files changed, 10 insertions(+), 2 deletions(-) diff --git

> Nope, you want non-trapping instructions. If you use trapping > instructions, C99 functions like isgreater will not work correctly with > NAN's. How do I know when to use a trapping instruction? For example consider this C function: ------------------------ int f(float a, float b) { return a <= b; } ------------------------ gcc uses fcmpes instead of fcmps... >

Hi, > James, is that a correct assessment? Yes, it is also my belief that the only way ARMv7 NEON differs from IEEE754 is lack of denormal support. James > On 11 Feb 2016, at 10:53, Renato Golin <renato.golin at linaro.org> wrote: > > Hal, > > I had a read on the ARM ARM about VFP and SIMD FP semantics and my > analysis is that NEON's only problem is the

Peter, Could you please comment on: http://llvm.org/bugs/show_bug.cgi?id=12757 Specifically, gcc seems to allow this: int __flt_rounds() { unsigned long fpscr; __asm__ volatile("mffs %0" : "=f"(fpscr)); return fpscr; } My reading of this is that gcc allocates a floating-point register to hold the result of the mffs instruction, and then bit casts (and truncates?) the

This series of patches makes Xen pass a (somewhat) valid device tree to dom0. The device tree for dom0 is the same as the one supplied to Xen except the memory and chosen nodes are adjusted appropriately. We don''t yet make use of the device tree to map MMIO regions or setup interrupts for the guest and we still include the UART used for Xen''s console. Note that loading Linux

Hi Oleg, On 01/09/14 18:46, Oleg Ranevskyy wrote: > Hi Duncan, > > I looked through the IEEE standard and here is what I found: > > *6.2 Operations with NaNs* > /"For an operation with quiet NaN inputs, other than maximum and minimum > operations, if a floating-point result is to be delivered the result shall be a > quiet NaN which should be one of the input

>------- Original Message ------- >Sender : Julien Grall<julien.grall@linaro.org> >Date : 2013-10-07 21:49 (GMT+09:00) >Title : Re: [Xen-devel] [PATCH v4 1/9] xen/arm: Implement hvm save and restore > >On 10/04/2013 05:43 AM, Jaeyong Yoo wrote: >> Implement save/restore of hvm context hypercall. In hvm >> context save/restore, we save gic, timer and vfp

On Fri, 2012-04-27 at 14:54 -0500, Hal Finkel wrote: > There is a comment in the file which reads: > > /* The weird 'i#*X' constraints on the following suppress a gcc > warning when __excepts is not a constant. Otherwise, they mean the > same as just plain 'i'. */ [sinp] > ("mtfsb0 %s0" : : "i#*X"(__builtin_ffs (__excepts))); [snip]