search for: idle_vcpu

...n = 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:24:09 2012 +0900 @@ -0,0 +1,51 @@ +#include <xen/config.h&g...

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

...efore it there are more CPUs >than >VCPUs, something goes wrong... > Yes, there''s only one idle domain now. However I''m not sure why something will go wrong when NR_CPUS > MAX_VIRT_CPUS. As long as you want to wake up an AP, you have to go through do_boot_cpu where idle_vcpu will be created. The only drawback is that some physical cpus will not be waken up by "max_cpus = MAX_VIRT_CPUS" you mentioned in another thread. That needs to be fixed which however shouldn''t crash anything since uninitialized cpus won''t be used. Thanks, Kevin ___...

...26:10 2006 -0600 +++ b/xen/arch/ia64/xen/xensetup.c Tue Aug 08 12:18:04 2006 -0600 @@ -423,13 +423,14 @@ void start_kernel(void) (xenheap_phys_end-__pa(heap_start)) >> 20, (xenheap_phys_end-__pa(heap_start)) >> 10); + late_setup_arch(&cmdline); + scheduler_init(); idle_vcpu[0] = (struct vcpu*) ia64_r13; idle_domain = domain_create(IDLE_DOMAIN_ID); if ( (idle_domain == NULL) || (alloc_vcpu(idle_domain, 0, 0) == NULL) ) BUG(); - late_setup_arch(&cmdline); alloc_dom_xen_and_dom_io(); setup_per_cpu_areas(); mem_init(); _______...

Hi, This is the fifth version of this patch series. With the Versatile Express TC2, it''s possible to boot only with A7 or A15. If the user choose to boot with only A7, the CPU ID will start at 0x100. As Xen relies on it to set the logical ID and the GIC, it won''t be possible to use Xen with this use case. This patch series is divided in 3 parts: - Patch 1: prepare Xen

Modify the cpufreq ondemand governor so that it can get idle and total ticks from the Xen hypervisor. Linux and Xen have different ideas of what an idle tick is, so the Xen values for both have to be returned in the same platform hypercall. Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> diff -r b4278beaf354 xen/arch/x86/platform_hypercall.c --- a/xen/arch/x86/platform_hypercall.c

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

George has release acked all of these. Otherwise mostly minor updates this time around. Summary: A == acked, M == modified A xen: arm64: Add 8250 earlyprintk support A xen: arm64: Add Basic Platform support for APM X-Gene Storm. A xen: arm64: Add APM implementor id to processor implementers. M xen: arm: add a quirk to handle platforms with unusual GIC layout A xen: arm: allow platform

Hello, This small series deals with some weirdness in the mechanism with which the credit scheduler choses what PCPU to tickle upon a VCPU wake-up. Details are available in the changelog of the first patch. The new approach has been extensively benchmarked and proved itself either beneficial or harmless. That means it does not introduce any significant amount of overhead and/or performances

Hi all, these are the remaining unapplied patches of the ARM HDLCD patch series. Changes in v7: - rebased on b61ed421d2c85b5b106c63f2c14f8aa162b282f0; - turn more printk and panic into early_printk and early_panic. Changes in v6: - rebased on 77d3a1db3196b1b5864469f8d3f41d496800c795; - remove useless initializations to NULL in lfb_init; - more compact checks in lfb_init. Changes in v5: - move

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.

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

This patch series is a reworking of a series developed by Mukesh Rathor at Oracle. The entirety of the design and development was done by him; I have only reworked, reorganized, and simplified things in a way that I think makes more sense. The vast majority of the credit for this effort therefore goes to him. This version is labelled v13 because it is based on his most recent series, v11.