[Xen-devel] Possible bug on ARM with irq passthrough
Hello, I'm testing IRQ latency on exynos5422. I'm using Xen 4.10-unstable. I used device passthrough for SPI irq 64. For guest domain I used FreeRTOS. When I use credit scheduler after destruction of domain, IRQ is released. I changed scheduler to credit2 and rtds at boot time and IRQ wasn't released after destruction. xl create dom-free-rtos.cfg fails with: libxl: error: libxl_create.c:1278:domcreate_launch_dm: Domain 5:failed give domain access to irq 64: Device or resource busy This is very strange because it doesn't happen with credit scheduler. This is output of xl dmesg: (XEN) IRQ 64 is already used by domain 1 Everything works first time but when I destroy domain and try to create again it fails. It works normally with credit scheduler. In dom-free-rtos.cfg: ... irqs = [64] Regards, Ivan Pavic ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Odgovor: Basic bare metal ARM domain interface
Hello, >> I used FreeRTOS code for console output. It is based on Mini OS code. There >> are two problems as I've >determined >> with debugging. First is that vsnprintf blocks for some reason in print >> function so i commented it out. After the >snprintf blocks... >> hypercall function blocked as well. I modified hypercall function so it >> looks like this: >>(void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes"); >As the call failed I decided to make hypervisor call directly in boot >procedure, so I put this assembler code just >before >branch to main: >mov r12, #18 ; console io code >mov r0, #0 ; write operation(first parameter) >mov r1, #5 ; length of message (second parameter) > ldr r2, =msg ; message address (third parameter) >.long 0xe140ea71 ; hvc instruction >b main ; branch to main >msg is defined as: >msg: >.asciz "hello" >I get deadbeef in registers, apperently something happened (xenctx output): >PC: 4000c5bc >CPSR: 61f3 >USR: SP: LR: >SVC: SPSR: SP:4011c200 LR:400080a8 >FIQ: SPSR: SP:40124200 LR: >IRQ: SPSR: SP:40120200 LR: >ABT: SPSR: SP:40128200 LR: >UND: SPSR: SP:4012c200 LR: >r0_usr: r1_usr: deadbeefr2_usr: deadbeef >r3_usr: r4_usr: r5_usr: >r6_usr: r7_usr: r8_usr: >r9_usr: 0064 r10_usr: 0064 r11_usr: >r12_usr: deadbeef >According to arch-arm.h r0 is return value of call. It is 0, operation >successful Still I don't get output on >console... >Thank you in advance, >Regards, >Ivan Pavic I still didn't solve why I don't see no output on emergency console, I think I should because if deadbeef in registers it do_console_io should have been called. However new problem emerged i tried to add iomem parameter in configuration file to get access over gpio but domain won't start because operation is not permitted. Should I somehow release disable that memory space for dom0, perhaps in dts for dom0? Snippet from dom.cfg file: iomem = ["0x1340,1@0x4140"] 0x1340 is base address of GPIO that I want to use. I get this error: (snippet from xl -vvv create -c dom.cfg) libxl: debug: libxl_create.c:1213:domcreate_launch_dm: dom4 iomem 1340-1340 libxl: error: libxl_create.c:1220:domcreate_launch_dm: failed give dom4 access to iomem range 1340-1340: Operation not permitted libxl: debug: libxl.c:1719:devices_destroy_cb: forked pid 3835 for destroy of domain 4 Thank you in advance, Ivan Pavic ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Basic bare metal ARM domain interface
Hello, > I used FreeRTOS code for console output. It is based on Mini OS code. There > are two problems as I've determined > with debugging. First is that vsnprintf blocks for some reason in print > function so i commented it out. After the snprintf blocks... > hypercall function blocked as well. I modified hypercall function so it looks > like this: > (void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes"); As the call failed I decided to make hypervisor call directly in boot procedure, so I put this assembler code just before branch to main: mov r12, #18 ; console io code mov r0, #0 ; write operation(first parameter) mov r1, #5 ; length of message (second parameter) ldr r2, =msg ; message address (third parameter) .long 0xe140ea71 ; hvc instruction b main ; branch to main msg is defined as: msg: .asciz "hello" I get deadbeef in registers, apperently something happened (xenctx output): PC: 4000c5bc CPSR: 61f3 USR: SP: LR: SVC: SPSR: SP:4011c200 LR:400080a8 FIQ: SPSR: SP:40124200 LR: IRQ: SPSR: SP:40120200 LR: ABT: SPSR: SP:40128200 LR: UND: SPSR: SP:4012c200 LR: r0_usr: r1_usr: deadbeefr2_usr: deadbeef r3_usr: r4_usr: r5_usr: r6_usr: r7_usr: r8_usr: r9_usr: 0064 r10_usr: 0064 r11_usr: r12_usr: deadbeef According to arch-arm.h r0 is return value of call. It is 0, operation successful Still I don't get output on console... Thank you in advance, Regards, Ivan Pavic ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Basic bare metal ARM domain interface
Hello, Jullien, thanks for docs and references. I used FreeRTOS code for console output. It is based on Mini OS code. There are two problems as I've determined with debugging. First is that vsnprintf blocks for some reason in print function so i commented it out. After the hypercall function blocked as well. I modified hypercall function so it looks like this: (void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes"); hoping to get "yes" as output..., but this blocked as well. xenctx output after HYPERVISOR_console_io: PC: 4000828c CPSR: 21d7 USR: SP: LR: SVC: SPSR: SP:4011bff4 LR:4000a37f FIQ: SPSR: SP:40124200 LR: IRQ: SPSR: SP:40120200 LR: ABT: SPSR:21f7 SP:40008140 LR:3f741306 UND: SPSR: SP:4012c200 LR: r0_usr: 4000815fr1_usr: r2_usr: 40008160 r3_usr: 4000815cr4_usr: a338r5_usr: 4000c948 r6_usr: r7_usr: 4000a53cr8_usr: r9_usr: r10_usr: 0065 r11_usr: r12_usr: r8_fiq: r9_fiq: r10_fiq: r11_fiq: r12_fiq: SCTLR: 00c50078 TTBCR: TTBR0: TTBR1: r10 = 101, I used it for debugging, to locate code where it is stuck. What could it be? Thanks in advance, Ivan Pavic. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Basic bare metal ARM domain interface
Hello, I'm working on bare metal application for ARM Cortex A7/15 on Odroid XU3 platform. I'm using Xen 4.6. After successfully creating bare metal example(by successful I mean I've stuck processor in while loop in main function), I probably should initialize memory management unit and similiar. I've found FreeRTOS project on Github where similiar stuff was done for ARM Cortex A15. Project is done for Xen 4.4. Xen FreeRTOS project: https://github.com/GaloisInc/FreeRTOS-Xen/ . 1) I'm using 4.6. so I don't know if code from is fully compatible? (I had to comment out lot of things because they block program, printing for example) 2) Additionally , I would like to implement basic serial output to dom0 from my bare metal domU. What is the minimum one should do for implementing console output? 3) Furthermore, as this should be bare metal application, I would like at least to be able to toggle LED. How can interface hardware from domU? My first guess would be to directly address Exynos 5422 GPIO registers but I don't know if that would work beacause application is running on VCPU (probably not??) ?? Any answer, example of implementation, specific documentation or advice would be very helpful. Thank you in advance... Regards, Ivan Pavić ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] ARM bare metal application test
Hello, > I don't think toolstack tries to load kernel to that guest physical > address -- reading from Ivan's log it suggests toolstack loaded the > kernel to 0x40008000. > That (0x8000800) is the address set in PC, right? I don't think > toolstack is in a position to sanitise that nor should it care. I posted xl create output when i changed address in linker script. This output when it is set to 0x80008000: PC is incorrect? Parsing config from dom.cfg libxl: debug: libxl_create.c:1557:do_domain_create: ao 0x3c1c8: create: how=(nil) callback=(nil) poller=0x3c228 libxl: debug: libxl_arm.c:59:libxl__arch_domain_prepare_config: Configure the domain libxl: debug: libxl_arm.c:62:libxl__arch_domain_prepare_config: - Allocate 0 SPIs libxl: debug: libxl_create.c:945:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:330:libxl__bootloader_run: no bootloader configured, using user supplied kernel libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch w=0x363a0: deregister unregistered domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)" libxl: debug: libxl_dom.c:624:libxl__build_pv: pv kernel mapped 0 path kernel.bin domainbuilder: detail: xc_dom_kernel_file: filename="kernel.bin" domainbuilder: detail: xc_dom_boot_xen_init: ver 4.6, caps xen-3.0-armv7l domainbuilder: detail: xc_dom_rambase_init: RAM starts at 4 domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) loader ... domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel image too small domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) loader ... domainbuilder: detail: loader probe OK domainbuilder: detail: xc_dom_parse_zimage32_kernel: called domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x40008000 -> 0x40008034 libxl: debug: libxl_arm.c:776:libxl__arch_domain_init_hw_description: constructing DTB for Xen version 4.6 guest libxl: debug: libxl_arm.c:777:libxl__arch_domain_init_hw_description: - vGIC version: V2 libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder node /memory@4000 libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder node /memory@2 libxl: debug: libxl_arm.c:871:libxl__arch_domain_init_hw_description: fdt total size 1237 domainbuilder: detail: xc_dom_devicetree_mem: called domainbuilder: detail: xc_dom_mem_init: mem 32 MB, pages 0x2000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x2000 pages domainbuilder: detail: xc_dom_boot_mem_init: called domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32 domainbuilder: detail: populate_guest_memory: populating RAM @ 4000-4200 (32MB) domainbuilder: detail: populate_one_size: populated 0x10/0x10 entries with shift 9 domainbuilder: detail: arch_setup_meminit: placing boot modules at 0x41fff000 domainbuilder: detail: arch_setup_meminit: devicetree: 0x41fff000 -> 0x4200 libxl: debug: libxl_arm.c:902:finalise_one_memory_node: Populating placeholder node /memory@4000 libxl: debug: libxl_arm.c:896:finalise_one_memory_node: Nopping out placeholder node /memory@2 domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000 -> 0x40009000 (pfn 0x40008 + 0x1 pages) domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x40008+0x1 at 0xb6eef000 domainbuilder: detail: xc_dom_load_zimage_kernel: called domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg 0x40008000-0x40009000 domainbuilder: detail: xc_dom_load_zimage_kernel: copy 52 bytes from blob 0xb6ef to dst 0xb6eef000 domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x41fff000 -> 0x4200 (pfn 0x41fff + 0x1 pages) domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x41fff+0x1 at 0xb6eee000 domainbuilder: detail: alloc_magic_pages: called domainbuilder: detail: count_pgtables_arm: called domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x4200 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0 domainbuilder: detail: xc_dom_boot_image: called domainbuilder: detail: arch_setup_bootearly: doing nothing domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-armv7l <= matches domainbuilder: detail: setup_pgtables_arm: called domainbuilder: detail: clear_page: pfn 0x39000, mfn 0x39000 domainbuilder: detail: clear_page: pfn 0x39001, mfn 0x39001 domainbuilder: detail: start_info_arm: called domainbuilder: detail: domain builder memory footprint domainbuilder: detail:allocated domainbuilder: detail: malloc : 66 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder:
[Xen-devel] ARM bare metal application test
Hello Julien, Julien Grall wrote: > Guest are booting with MMU disabled, so 0x80008000 will be the physical > address. > The toolstack will load the kernel at this physical address. However, > the start of the guest RAM for Xen 4.7 is 0x4000 (see > include/public/arch-arm.h). Can you try to use 0x40008000 for the guest > address? I changed address. It seems the problem is solved because PC is now 40008030 (that is address of "work: b work" i think). > By the way, how much RAM did you give to the guest? I wrote "memory = 32" in cfg file, I think that stands for 32 MB? I will continue working on this. Thank you very much, Ivan Pavić. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Odgovor: ARM bare metal application test
Hello, > Correct, so the end of the RAM bank would be 0x4200. I am a bit > surprised that the toolstack does not complain when trying to load the > kernel at 0x80008000. > Can you paste the dump of xl -vvv create... ? $ xl -vvv create dom.cfg Parsing config from dom.cfg libxl: debug: libxl_create.c:1557:do_domain_create: ao 0x3c1c8: create: how=(nil) callback=(nil) poller=0x3c228 libxl: debug: libxl_arm.c:59:libxl__arch_domain_prepare_config: Configure the domain libxl: debug: libxl_arm.c:62:libxl__arch_domain_prepare_config: - Allocate 0 SPIs libxl: debug: libxl_create.c:945:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:330:libxl__bootloader_run: no bootloader configured, using user supplied kernel libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch w=0x363a0: deregister unregistered domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)" libxl: debug: libxl_dom.c:624:libxl__build_pv: pv kernel mapped 0 path kernel.bin domainbuilder: detail: xc_dom_kernel_file: filename="kernel.bin" domainbuilder: detail: xc_dom_boot_xen_init: ver 4.6, caps xen-3.0-armv7l domainbuilder: detail: xc_dom_rambase_init: RAM starts at 4 domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) loader ... domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel image too small domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) loader ... domainbuilder: detail: loader probe OK domainbuilder: detail: xc_dom_parse_zimage32_kernel: called domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x40008000 -> 0x40008034 libxl: debug: libxl_arm.c:776:libxl__arch_domain_init_hw_description: constructing DTB for Xen version 4.6 guest libxl: debug: libxl_arm.c:777:libxl__arch_domain_init_hw_description: - vGIC version: V2 libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder node /memory@4000 libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder node /memory@2 libxl: debug: libxl_arm.c:871:libxl__arch_domain_init_hw_description: fdt total size 1237 domainbuilder: detail: xc_dom_devicetree_mem: called domainbuilder: detail: xc_dom_mem_init: mem 32 MB, pages 0x2000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x2000 pages domainbuilder: detail: xc_dom_boot_mem_init: called domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32 domainbuilder: detail: populate_guest_memory: populating RAM @ 4000-4200 (32MB) domainbuilder: detail: populate_one_size: populated 0x10/0x10 entries with shift 9 domainbuilder: detail: arch_setup_meminit: placing boot modules at 0x41fff000 domainbuilder: detail: arch_setup_meminit: devicetree: 0x41fff000 -> 0x4200 libxl: debug: libxl_arm.c:902:finalise_one_memory_node: Populating placeholder node /memory@4000 libxl: debug: libxl_arm.c:896:finalise_one_memory_node: Nopping out placeholder node /memory@2 [0/47] domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000 -> 0x40009000 (pfn 0x40008 + 0x1 pages) domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x40008+0x1 at 0xb6f82000 domainbuilder: detail: xc_dom_load_zimage_kernel: called domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg 0x40008000-0x40009000 domainbuilder: detail: xc_dom_load_zimage_kernel: copy 52 bytes from blob 0xb6f83000 to dst 0xb6f82000 domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x41fff000 -> 0x4200 (pfn 0x41fff + 0x1 pages) domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x41fff+0x1 at 0xb6f81000 domainbuilder: detail: alloc_magic_pages: called domainbuilder: detail: count_pgtables_arm: called domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x4200 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0 domainbuilder: detail: xc_dom_boot_image: called domainbuilder: detail: arch_setup_bootearly: doing nothing domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-armv7l <= matches domainbuilder: detail: setup_pgtables_arm: called domainbuilder: detail: clear_page: pfn 0x39000, mfn 0x39000 domainbuilder: detail: clear_page: pfn 0x39001, mfn 0x39001 domainbuilder: detail: start_info_arm: called domainbuilder: detail: domain builder memory footprint domainbuilder: detail:allocated domainbuilder: detail: malloc : 66 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder: detail:mapped domainbuilder: detail: file mmap : 52 bytes domainbuilder: detail: domU mmap
[Xen-devel] Odgovor: ARM bare metal application test
Konrad Rzeszutek Wilk wrote: > OK, but that makes an ELF file. I believe (based on the Booting) you need to > extract > the binary code out and also fixup the branch instructions (maybe make > __Start = 0;?). > The Booting says: > - The boot loader is expected to call the kernel image by jumping > directly to the first instruction of the kernel image. > So if it is ELF it will jump in the ELF header, not the cod Ok, this is objdump -h app.elf Sections: Idx Name Size VMA LMA File off Algn 0 .text 0034 80008000 80008000 8000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .ARM.attributes 001f 8034 2**0 CONTENTS, READONLY I extracted binary with objcopy and used it to start domain: Segment of output of: xl -vvv create dom.cfg ... domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) loader ... domainbuilder: detail: loader probe OK domainbuilder: detail: xc_dom_parse_zimage32_kernel: called ... domainbuilder: detail: vcpu_arm32: called domainbuilder: detail: Initial state CPSR 0x1d3 PC 0x80008000 ... Only thing I can think of is that I'm accessing memory I can't access by default of MMU and that causes prefetch abort but I don't know which memory segment I can use? Regards, Ivan Pavic. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] ARM bare metal application test
Julien Grail wrote:
> You can dump the registers of a vCPU with xenctx.
> $PREFIX/lib/xen/bin/xenctx domid
> $PREFIX is the path where xen tools have been installed (i.e --prefix on
> the configure). The default path is /usr/local/
Thanks for advice. I discovered that the PC has value 0x0C and SPSR of ABT mode
is same
as CPSR so I think that is prefetch abort. But I don't understand why it
happens? Invalid memory
access? I'm using simple linker script:
...
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
_start = 0x80008000;
. = _start;
.text : {
*(.start);
*(.text);
}
...
Thanks in advance.
Ivan Pavić
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] ARM bare metal application test
Hello, I'm trying to build simple bare metal application on ARM Cortex A7. I reached the phase in which I successfully created domain. Now, I would like to check if application is really running (it runs according xl list). But i need some simple interaction or at least console output. So far this is my code: .section ".start", "x" .align .globl_start _start: @ zImage header .rept 8 mov r0, r0 .endr b work .word 0x016f2818 @ Magic numbers to help the loader .word _start @ absolute load/run zImage address .word _end - _start @ zImage size @ end of zImage header work: b work I've made linker script so that entry point is at address _start and it is initial value of PC (it is 0x80008000). So is there any quick way to check registers from dom0 so I can be sure that "work" is being done? I'm testing this on Odroid XU3 platform... ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Odroid XU3 support
> Xen is not ready for big.LITTLE, so I would highly recommend you to > disable either all the Cortex-A15 or Cortex-A7. > For your information, I am planning to send a patch to park any CPUs > whose MIDR is not matching the boot CPU one. > Julien Grall Ok, I decided to use A15s... How can I disable A7s in software and use only A15s... Additionally how can I be sure that I'm using A15 cluster? This maybe more ODROID related: Suriyan Ramasami wrote: > The Odroid XU3/XU4 afaict has a hardware pin which dictates if a A7 > or an A15 core should boot up. It is currently set to boot up from the A7s. This may sound silly but where is that PIN on XU3 board.? Can this be modfied(is it accessible)? If not, how can I do it in software... Where to change order? Where to disable A7s? Probably in uBoot? Regards, Ivan Pavic. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Odroid XU3 support
Hello, i'm trying to boot dom0 linux on exynos5422 platform on A15 (big cpu cluster). From the past mailing lists on this link: http://lists.xen.org/archives/html/xen-devel/2016-02/msg02275.html) I'm not sure that is well defined how to change A7's for A15's. Should change be in DTS or should one change cpu power up routines in linux? So far every time it boots from A7's. Additionally, I found this in xen boot.ini file: # use the A7s for dom0 and pin them to it setenv xen_bootargs sync_console console=dtuart dtuart=/serial@12C2 \ dom0_mem=800M dom0_max_vcpus=4 dom0_vcpus_pin How this defines A7s for dom0? How can I check which core is currently active? Judging by this link on big.LITTLE architecture: http://forum.odroid.com/viewtopic.php?f=65=2580 result of: cat /proc/cpuinfo | grep "CPU part" is CPU part: 0xc07 which stands for A7. Regards, Ivan Pavic. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
