search for: vector_irq

Hi, I''ve still have problems with ACPI(?) on Xen. After some system startup or resume CPU temperature goes high although all domUs (and dom0) are idle. On "good" system startup it is about 50-55C, on "bad" - above 67C (most time above 70C). I''ve noticed difference in C-states repored by Xen (attached files). On "bad" startups in addition suspend

...ed Jun 8 23:08:01 2005 +++ b/xen/arch/x86/vmx.c Thu Jun 9 01:03:30 2005 @@ -1262,8 +1262,7 @@ if (vector == LOCAL_TIMER_VECTOR) { smp_apic_timer_interrupt(&regs); } else { - regs.entry_vector = (vector == FIRST_DEVICE_VECTOR? - 0 : vector_irq[vector]); + regs.entry_vector = vector; do_IRQ(&regs); } break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...(cfg->vector == vector) && cpus_equal(cfg->domain, domain)) + if ((cfg->vector == vector) && cpus_equal(cfg->domain, mask)) return 0; if (cfg->vector != IRQ_VECTOR_UNASSIGNED) return -EBUSY; for_each_cpu_mask(cpu, mask) per_cpu(vector_irq, cpu)[vector] = irq; cfg->vector = vector; - cfg->domain = domain; + cfg->domain = mask; irq_status[irq] = IRQ_USED; if (IO_APIC_IRQ(irq)) irq_vector[irq] = vector;

...setof(struct arch_vcpu_info, far)); + BLANK(); + DEFINE(OFFSET_GUEST_CONTEXT, offsetof(struct arch_vcpu, ctx)); + DEFINE(OFFSET_VECTOR_RESET, 0); + DEFINE(OFFSET_VECTOR_UND, 4); + DEFINE(OFFSET_VECTOR_SWI, 8); + DEFINE(OFFSET_VECTOR_PABT, 12); + DEFINE(OFFSET_VECTOR_DABT, 16); + DEFINE(OFFSET_VECTOR_IRQ, 24); + DEFINE(OFFSET_VECTOR_FIQ, 28); + BLANK(); + DEFINE(OFFSET_VCPU, offsetof(struct cpu_info, vcpu)); + DEFINE(OFFSET_VPSR, offsetof(struct cpu_info, vspsr)); + DEFINE(OFFSET_VSP, offsetof(struct cpu_info, vsp)); + DEFINE(OFFSET_VLR, offsetof(struct cpu_info, vlr)); + BLANK(); + DEFIN...

...HW_IRQ_H */ diff -r 7750906b06b3 -r 31f09a5e24cf xen/include/asm-x86/msi.h --- a/xen/include/asm-x86/msi.h Wed Sep 24 10:23:51 2008 +0100 +++ b/xen/include/asm-x86/msi.h Wed Sep 24 12:36:55 2008 +0100 @@ -106,7 +106,7 @@ struct msi_desc { */ #define NR_HP_RESERVED_VECTORS 20 -extern int vector_irq[NR_VECTORS]; +extern struct hw_interrupt_type pci_msi_type; /* * MSI-X Address Register diff -r 7750906b06b3 -r 31f09a5e24cf xen/include/xen/irq.h --- a/xen/include/xen/irq.h Wed Sep 24 10:23:51 2008 +0100 +++ b/xen/include/xen/irq.h Wed Sep 24 12:36:55 2008 +0100 @@ -22,7 +22,6 @@ stru...

This set of patches converts the way frames gets created from using PUSHes/POPs to using MOVes, thus allowing (in certain cases) to avoid saving/restoring part of the register set. While the place where the (small) win from this comes from varies between CPUs, the net effect is a 1 to 2% reduction on a combined interruption entry and exit when the full state save can be avoided. 1: use MOV

There is a BUG_ON() at xen/arch/x86/physdev.c:169 which appears to be dependent upon guest behavior (should close event channel before un-mapping pirq), rather than on internal hypervisor state. In 2.6.18, this likely goes unnoticed because pci_device_shutdown() only calls all the driver shutdown routines. In newer kernels, however, it also calls pci_msi_shutdown() and pci_msix_shutdown(), which

...-} - -void __init vmi_time_init(void) -{ - unsigned int cpu; - /* Disable PIT: BIOSes start PIT CH0 with 18.2hz peridic. */ - outb_pit(0x3a, PIT_MODE); /* binary, mode 5, LSB/MSB, ch 0 */ - - vmi_time_init_clockevent(); - setup_irq(0, &vmi_clock_action); - for_each_possible_cpu(cpu) - per_cpu(vector_irq, cpu)[vmi_get_timer_vector()] = 0; -} - -#ifdef CONFIG_X86_LOCAL_APIC -void __devinit vmi_time_bsp_init(void) -{ - /* - * On APIC systems, we want local timers to fire on each cpu. We do - * this by programming LVTT to deliver timer events to the IRQ handler - * for IRQ-0, since we can't re...

...-} - -void __init vmi_time_init(void) -{ - unsigned int cpu; - /* Disable PIT: BIOSes start PIT CH0 with 18.2hz peridic. */ - outb_pit(0x3a, PIT_MODE); /* binary, mode 5, LSB/MSB, ch 0 */ - - vmi_time_init_clockevent(); - setup_irq(0, &vmi_clock_action); - for_each_possible_cpu(cpu) - per_cpu(vector_irq, cpu)[vmi_get_timer_vector()] = 0; -} - -#ifdef CONFIG_X86_LOCAL_APIC -void __devinit vmi_time_bsp_init(void) -{ - /* - * On APIC systems, we want local timers to fire on each cpu. We do - * this by programming LVTT to deliver timer events to the IRQ handler - * for IRQ-0, since we can't re...

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Now all the comments so far have been addressed, but only a few exceptions. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops.

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Now all the comments so far have been addressed, but only a few exceptions. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops.

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Please review and comments. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops. Currently only ia64/xen pv_ops implementation

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Please review and comments. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops. Currently only ia64/xen pv_ops implementation

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops

Hi. This patchset implements xen/ia64 domU support. Qing He and Eddie Dong also has been woring on pv_ops so that I want to discuss before going further and avoid duplicated work. I suppose that Eddie will also post his own patch. So reviewing both patches, we can reach to better pv_ops interface. - I didn't changed the ia64 intrinsic paravirtulization abi from the last post. Presumably it

Hi. This patchset implements xen/ia64 domU support. Qing He and Eddie Dong also has been woring on pv_ops so that I want to discuss before going further and avoid duplicated work. I suppose that Eddie will also post his own patch. So reviewing both patches, we can reach to better pv_ops interface. - I didn't changed the ia64 intrinsic paravirtulization abi from the last post. Presumably it