search for: io_apic_route_entry

The patch moves the struct IO_APIC_route_entry to a common place. This allows us to share the struct with iosapic. Thanks, -- Dexuan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

....com> diff -r 4b0692880dfa -r 35abcbcdf8bc xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Thu May 05 17:40:34 2011 +0100 +++ b/xen/arch/x86/io_apic.c Mon May 09 11:43:35 2011 +0100 @@ -156,6 +156,52 @@ nomem: return 0; } +union entry_union { + struct { u32 w1, w2; }; + struct IO_APIC_route_entry entry; +}; + +static struct IO_APIC_route_entry __ioapic_read_entry(int apic, int pin, int raw) +{ + unsigned int (*read)(unsigned int, unsigned int) + = raw ? __io_apic_read : io_apic_read; + union entry_union eu; + eu.w1 = (*read)(apic, 0x10 + 2 * pin); + eu.w2 = (*read)(apic,...

....com> diff -r 4b0692880dfa -r 35abcbcdf8bc xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Thu May 05 17:40:34 2011 +0100 +++ b/xen/arch/x86/io_apic.c Mon May 09 11:43:35 2011 +0100 @@ -156,6 +156,52 @@ nomem: return 0; } +union entry_union { + struct { u32 w1, w2; }; + struct IO_APIC_route_entry entry; +}; + +static struct IO_APIC_route_entry __ioapic_read_entry(int apic, int pin, int raw) +{ + unsigned int (*read)(unsigned int, unsigned int) + = raw ? __io_apic_read : io_apic_read; + union entry_union eu; + eu.w1 = (*read)(apic, 0x10 + 2 * pin); + eu.w2 = (*read)(apic,...

...pic.c --- a/xen/arch/x86/io_apic.c Tue May 08 10:21:23 2007 +0100 +++ b/xen/arch/x86/io_apic.c Mon May 14 15:09:20 2007 -0400 @@ -1793,6 +1793,78 @@ void __init setup_IO_APIC(void) register_keyhandler(''z'', print_IO_APIC_keyhandler, "print ioapic info"); } +struct IO_APIC_route_entry *ioapic_pm_state=NULL; + +void ioapic_pm_state_alloc(void) +{ + int i, nr_entry=0; + + if (ioapic_pm_state!=NULL) + return; + + for (i=0; i<nr_ioapics; i++) + nr_entry += nr_ioapic_registers[i]; + ioapic_pm_state = _xmalloc( sizeof(struct IO_APIC_route_entry)*nr_en...

...gs); -} - -static void unmask_IO_APIC_irq (unsigned int irq) -{ - unsigned long flags; - - spin_lock_irqsave(&ioapic_lock, flags); - __unmask_IO_APIC_irq(irq); - spin_unlock_irqrestore(&ioapic_lock, flags); -} - -static void clear_IO_APIC_pin(unsigned int apic, unsigned int pin) -{ - struct IO_APIC_route_entry entry; - unsigned long flags; - - /* Check delivery_mode to be sure we're not clearing an SMI pin */ - spin_lock_irqsave(&ioapic_lock, flags); - *(((int*)&entry) + 0) = io_apic_read(apic, 0x10 + 2 * pin); - *(((int*)&entry) + 1) = io_apic_read(apic, 0x11 + 2 * pin); - spin_unlock_i...

...gs); -} - -static void unmask_IO_APIC_irq (unsigned int irq) -{ - unsigned long flags; - - spin_lock_irqsave(&ioapic_lock, flags); - __unmask_IO_APIC_irq(irq); - spin_unlock_irqrestore(&ioapic_lock, flags); -} - -static void clear_IO_APIC_pin(unsigned int apic, unsigned int pin) -{ - struct IO_APIC_route_entry entry; - unsigned long flags; - - /* Check delivery_mode to be sure we're not clearing an SMI pin */ - spin_lock_irqsave(&ioapic_lock, flags); - *(((int*)&entry) + 0) = io_apic_read(apic, 0x10 + 2 * pin); - *(((int*)&entry) + 1) = io_apic_read(apic, 0x11 + 2 * pin); - spin_unlock_i...

Hi, on a Nehalem system with VT-d enabled we are seeing strange ACPI-Table contents, especially a corrupted DMAR entry. The hypervisor shows following data on boot: (XEN) ACPI: RSDP 000F80E0, 0024 (r2 PTLTD ) (XEN) ACPI: XSDT BF7C469E, 00D4 (r1 PTLTD XSDT 60000 LTP 0) (XEN) ACPI: FACP BF7C9CC9, 00F4 (r3 FSC TYLERBRG 60000 PTL F4240) (XEN) ACPI: DSDT BF7C4772, 54D3 (r1

1: IOMMU: properly check whether interrupt remapping is enabled 2: AMD IOMMU: only disable when certain IVRS consistency checks fail 3: VT-d: deal with 5500/5520/X58 errata Patch 1 and 2 are version 2 of a previously submitted, then withdrawn patch following up after XSA-36. Patch 3 is version 3 of a patch previously sent by Malcolm and Andrew. Signed-off-by: Jan Beulich

...deletions(-) > > diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h > index 90f97b4..692a90f 100644 > --- a/arch/x86/include/asm/io_apic.h > +++ b/arch/x86/include/asm/io_apic.h > @@ -158,7 +158,7 @@ extern int native_setup_ioapic_entry(int, struct > IO_APIC_route_entry *, > struct io_apic_irq_attr *); > extern void eoi_ioapic_irq(unsigned int irq, struct irq_cfg *cfg); > > -extern void native_compose_msi_msg(struct pci_dev *pdev, > +extern void native_compose_msi_msg(struct msi_irqs *msi, > unsigned int irq, unsigned int dest...

...deletions(-) > > diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h > index 90f97b4..692a90f 100644 > --- a/arch/x86/include/asm/io_apic.h > +++ b/arch/x86/include/asm/io_apic.h > @@ -158,7 +158,7 @@ extern int native_setup_ioapic_entry(int, struct > IO_APIC_route_entry *, > struct io_apic_irq_attr *); > extern void eoi_ioapic_irq(unsigned int irq, struct irq_cfg *cfg); > > -extern void native_compose_msi_msg(struct pci_dev *pdev, > +extern void native_compose_msi_msg(struct msi_irqs *msi, > unsigned int irq, unsigned int dest...

...files changed, 72 insertions(+), 70 deletions(-) diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h index 90f97b4..692a90f 100644 --- a/arch/x86/include/asm/io_apic.h +++ b/arch/x86/include/asm/io_apic.h @@ -158,7 +158,7 @@ extern int native_setup_ioapic_entry(int, struct IO_APIC_route_entry *, struct io_apic_irq_attr *); extern void eoi_ioapic_irq(unsigned int irq, struct irq_cfg *cfg); -extern void native_compose_msi_msg(struct pci_dev *pdev, +extern void native_compose_msi_msg(struct msi_irqs *msi, unsigned int irq, unsigned int dest, struct msi_msg *msg...

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 all, The series is a draft of generic MSI driver that supports PCI and Non-PCI device which have MSI capability. If you're not interested it, sorry for the noise. The series is based on Linux-3.16-rc1. MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes are bonding with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use

Hi all, The series is a draft of generic MSI driver that supports PCI and Non-PCI device which have MSI capability. If you're not interested it, sorry for the noise. The series is based on Linux-3.16-rc1. MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes are bonding with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use