search for: arch_domain

...095ff 100644 --- a/xen/include/asm-arm/domain.h +++ b/xen/include/asm-arm/domain.h @@ -21,6 +21,7 @@ struct pending_irq struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */ uint8_t priority; struct list_head link; + struct list_head lr_link; }; struct arch_domain -- 1.7.2.5

...case? + */ + if ( n->domain->arch.dirty.mode ) + restore_vlpt(n->domain); + /* This is could trigger an hardware interrupt from the virtual * timer. The interrupt needs to be injected into the guest. */ virt_timer_restore(n); @@ -509,11 +515,19 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags) /* Default the virtual ID to match the physical */ d->arch.vpidr = boot_cpu_data.midr.bits; + /* init for dirty-page tracing */ + d->arch.dirty.count = 0; + d->arch.dirty.mode = 0; + spin_lock_init(&d->...

...ch/arm/xen/Makefile --- a/xen/arch/arm/xen/Makefile Fri Feb 03 17:28:34 2012 +0900 +++ b/xen/arch/arm/xen/Makefile Fri Feb 03 17:47:16 2012 +0900 @@ -1,5 +1,8 @@ obj-y += start.o obj-y += setup.o +obj-y += entry.o +obj-y += hypercalls.o +obj-y += physdev.o obj-y += mm.o obj-y += irq.o obj-y += arch_domain.o diff -r 28a6038da99f xen/arch/arm/xen/asm-offsets.c --- a/xen/arch/arm/xen/asm-offsets.c Fri Feb 03 17:28:34 2012 +0900 +++ b/xen/arch/arm/xen/asm-offsets.c Fri Feb 03 17:47:16 2012 +0900 @@ -34,6 +34,67 @@ int main(void) { + DEFINE(OFFSET_SOFTIRQ_PENDING, offsetof(struct irq_cpustat, __soft...

...+ out: spin_unlock_irqrestore(&desc->lock, flags); + return rc; } void diff -r 7750906b06b3 -r 31f09a5e24cf xen/arch/x86/domain.c --- a/xen/arch/x86/domain.c Wed Sep 24 10:23:51 2008 +0100 +++ b/xen/arch/x86/domain.c Wed Sep 24 12:36:55 2008 +0100 @@ -414,8 +414,6 @@ int arch_domain_create(struct domain *d, goto fail; } - spin_lock_init(&d->arch.irq_lock); - if ( is_hvm_domain(d) ) { if ( (rc = hvm_domain_initialise(d)) != 0 ) diff -r 7750906b06b3 -r 31f09a5e24cf xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Wed Sep 24 1...

I''ve put together two patches. The first introduces a new dom0_op, set_max_vcpus, which with an associated variable and a check in the VCPUOP handler fixes [1]bug 288. Also included is a new VCPUOP, VCPUOP_create, which handles all of the vcpu creation tasks and leaves initialization and unpausing to VCPUOP_initialize. The separation allows for build-time allocation of vcpus which

I just built 4.3.0 in order to get > 2GB of RAM in domU with GPU passthrough without crashes. Unfortunately, the same crashes still happen. Massive frame buffer corruption on domU before it locks up solid. It seems the PCI memory stomp is still happening. I am using qemu-dm, as I did on Xen 4.2.x. So whatever fix for this went into 4.3.0 didn''t fix it for me. Passing less than 2GB

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.

The following dump-core patches changes its format into ELF, adds PFN-GMFN table, HVM support, and adds experimental IA64 support. - ELF format Program header and note section are adopted. - HVM domain support To know the memory area to dump, XENMEM_set_memory_map is added. XENMEM_memory_map hypercall is for current domain, so new one is created. and hvm domain builder tell xen its

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.

...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 ARM stuff apart from stubbing out the x86 version of the new libxl__arch_domain_configure(). Summary: A==Acked M==Minor mods. So only one missing ack to go... A xen: arm: Report aarch64 capability. A xen: arm: Add comment regard arm64 zImage v0 vs v1 M xen: arm: move dom0 gic and timer device tree nodes under /xen-core-devices/ A M xen: arm: allocate dom0 memory se...

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 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