similar to: [PATCH] x86/IRQ: create_irq() should call assign_irq_vector()

Hi, With a fairly current kernel + xen, I''m seeing this if I rmmod iwlagn and try to reload it: [51230.646678] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree: [51230.646685] Copyright(c) 2003-2011 Intel Corporation [51230.646760] xen: registering gsi 17 triggering 0 polarity 1 [51230.646773] xen_map_pirq_gsi: returning irq 17 for gsi 17 [51230.646777] xen: --> pirq=17

XSA-36 changed the default vector map mode from global to per-device. This is because a global vector map does not prevent one PCI device from impersonating another and launching a DoS on the system. However, the per-device vector map logic is broken for devices with multiple MSI-X vectors, which can either result in a failed ASSERT() or misprogramming of a guests interrupt remapping tables.

OK, I need to do something like this to io_apic.c - split the hardware specific parts out under mach-default, so we can override them for other subarchitectures. It's not finished, needs header file and makefile work. Would you be willing to take this if I do it? I'm not going to bother if you're not, such refactorings are a pig to maintain out of tree. Frankly, io_apic.c needs a

OK, I need to do something like this to io_apic.c - split the hardware specific parts out under mach-default, so we can override them for other subarchitectures. It's not finished, needs header file and makefile work. Would you be willing to take this if I do it? I'm not going to bother if you're not, such refactorings are a pig to maintain out of tree. Frankly, io_apic.c needs a

Hi Alex: I was looking at an ia64 bug report and noticed that we don''t actually free IRQs in the free_irq_vector hypercall. This would eventually lead to alloc_irq_vector failing. Unless I''m mistaken something like calling pci_disable_device and pci_enable_device can lead to this situation. So I''m wondering what the original problem was and how could we resolve it

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1304937815 -3600 # Node ID 35abcbcdf8bcabab6e0bbd929f69b613e167edfd # Parent 4b0692880dfa557d4e1537c7a58c412c1286a416 xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables gcc 4.6 complains: io_apic.c: In function 'restore_IO_APIC_setup':

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1304937815 -3600 # Node ID 35abcbcdf8bcabab6e0bbd929f69b613e167edfd # Parent 4b0692880dfa557d4e1537c7a58c412c1286a416 xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables gcc 4.6 complains: io_apic.c: In function 'restore_IO_APIC_setup':

Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/hpet.c +++ b/xen/arch/x86/hpet.c @@ -296,7 +296,7 @@ static void hpet_msi_ack(unsigned int ir { struct irq_desc *desc = irq_to_desc(irq); - irq_complete_move(&desc); + irq_complete_move(desc); move_native_irq(irq); ack_APIC_irq(); } --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@

Currently the vector is not freed for MSI interrupt, the three patches fix the issue. The first patch(pirq.patch) move the get_free_pirq/map(unmap)_domain_pirq from arch/x86/physdev.c to arch/x86/irq.c, since that should be part of irq managment, no logic changes. The second patch(msi_vector_clean.patch) free the vector when the pirq is unmapped or when domain destroy. One thing need notice for

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 linux/ia64 developers. Few days before Eddie posted the mail for Linux/IA64 paravirtualization. But only a few responded partially because there was no reviewable patches. Here is the patches for xen/ia64 Linux paravirtualization. The goal is to merge IA64 xen Linux paravirtualization for both domU and dom0 eventually. However the first step is to merge domU portion. As you can see from the

flight 8091 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8091/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-intel 12 guest-localmigrate/x10 fail REGR. vs. 8071 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9

Samba mount (from one of our build scripts). We decided to upgrade to RedHat 7.2 (which uses a newer version of Samba -- 2.1.1b IIRC), maybe that fixes the problem. However, I decided to submit this bug report, in the hope that it may help kill some bugs. (Remember -- the only good bug, is a dead bug :)) So, here is the dmesg output: Linux version 2.2.16-22enterprise

Remove unused and pointless bits from mpparse.c (and other files where they are related to it). Of what remains, move whatever possible into .init.*, and some data items into .data.read_mostly. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- 2011-03-09.orig/xen/arch/x86/acpi/boot.c +++ 2011-03-09/xen/arch/x86/acpi/boot.c @@ -177,7 +177,8 @@ acpi_parse_x2apic(struct acpi_subtable_h

Add suspend/resume to devices owned by Xen. Signed-off-by Ke Yu <ke.yu@intel.com> Signed-off-by Kevin Tian <kevin.tian@intel.com> diff -r 3ef0510e44d0 xen/arch/x86/apic.c --- a/xen/arch/x86/apic.c Tue May 08 10:21:23 2007 +0100 +++ b/xen/arch/x86/apic.c Mon May 14 15:05:28 2007 -0400 @@ -579,6 +579,95 @@ void __devinit setup_local_APIC(void) apic_pm_activate(); } +static