Displaying 10 results from an estimated 10 matches for "mp_ioapics".
2007 Apr 18
2
refactoring io_apic.c
...O_APIC_reg_03 reg_03;
- unsigned long flags;
-
- if (apic_verbosity == APIC_QUIET)
- return;
-
- printk(KERN_DEBUG "number of MP IRQ sources: %d.\n", mp_irq_entries);
- for (i = 0; i < nr_ioapics; i++)
- printk(KERN_DEBUG "number of IO-APIC #%d registers: %d.\n",
- mp_ioapics[i].mpc_apicid, nr_ioapic_registers[i]);
-
- /*
- * We are a bit conservative about what we expect. We have to
- * know about every hardware change ASAP.
- */
- printk(KERN_INFO "testing the IO APIC.......................\n");
-
- for (apic = 0; apic < nr_ioapics; apic++) {
-
- spin...
2007 Apr 18
2
refactoring io_apic.c
...O_APIC_reg_03 reg_03;
- unsigned long flags;
-
- if (apic_verbosity == APIC_QUIET)
- return;
-
- printk(KERN_DEBUG "number of MP IRQ sources: %d.\n", mp_irq_entries);
- for (i = 0; i < nr_ioapics; i++)
- printk(KERN_DEBUG "number of IO-APIC #%d registers: %d.\n",
- mp_ioapics[i].mpc_apicid, nr_ioapic_registers[i]);
-
- /*
- * We are a bit conservative about what we expect. We have to
- * know about every hardware change ASAP.
- */
- printk(KERN_INFO "testing the IO APIC.......................\n");
-
- for (apic = 0; apic < nr_ioapics; apic++) {
-
- spin...
2011 Mar 09
0
[PATCH 04/11] x86: cleanup mpparse.c
...ocal [MAX_MP_BUSSES];
-int mp_bus_id_to_pci_bus [MAX_MP_BUSSES] = { [0 ... MAX_MP_BUSSES-1] = -1 };
-static int mp_current_pci_id;
+unsigned char __read_mostly apic_version[MAX_APICS];
+unsigned char __read_mostly mp_bus_id_to_type[MAX_MP_BUSSES];
/* I/O APIC entries */
-struct mpc_config_ioapic mp_ioapics[MAX_IO_APICS];
+struct mpc_config_ioapic __read_mostly mp_ioapics[MAX_IO_APICS];
/* # of MP IRQ source entries */
-struct mpc_config_intsrc mp_irqs[MAX_IRQ_SOURCES];
+struct mpc_config_intsrc __read_mostly mp_irqs[MAX_IRQ_SOURCES];
/* MP IRQ source entries */
-int mp_irq_entries;
+int __read_...
2013 May 02
5
[PATCH] x86: allow Dom0 read-only access to IO-APICs
...Linux upon encountering the
same kind of system.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -1114,7 +1114,7 @@ int __init construct_dom0(
for ( i = 0; i < nr_ioapics; i++ )
{
mfn = paddr_to_pfn(mp_ioapics[i].mpc_apicaddr);
- if ( smp_found_config )
+ if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
rc |= iomem_deny_access(dom0, mfn, mfn);
}
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2468,6 +2468,9 @@ void __init init_ioapic_mappings(void)...
2018 Feb 09
0
retpoline mitigation and 6.0
On Fri, 2018-02-09 at 12:54 +0000, David Woodhouse wrote:
> On Fri, 2018-02-09 at 10:36 +0000, David Woodhouse wrote:
> >
> > Did you get anywhere with the function attribute? Having isolated the
> > next boot failure to "it goes away if I compile io_apic.c without
> > retpoline", bisecting it per-function would help to further delay the
> > bit where I
2018 Feb 09
2
retpoline mitigation and 6.0
On Fri, 2018-02-09 at 10:36 +0000, David Woodhouse wrote:
>
> Did you get anywhere with the function attribute? Having isolated the
> next boot failure to "it goes away if I compile io_apic.c without
> retpoline", bisecting it per-function would help to further delay the
> bit where I actually have to start *thinking*...
It's mp_register_ioapic(), and only when
2018 Feb 09
3
retpoline mitigation and 6.0
I haven't read the all the emails in full detail, but it seems pretty clear
that __x86_indirect_thunk and __llvm_retpoline_push do not do the same
things. It sounds like __llvm_retpoline_push is equivalent to
__x86_indirect_thunk except first it swaps the two words on the top of the
stack.
I arranged it this way because the x86 call instruction puts the intended
return address on the top of
2007 May 15
3
[PATCH 1/12] Add suspend/resume to devices owned by Xen
..."can not resume ioapic due to lack of memory\n");
+ return 1;
+ }
+
+ entry = ioapic_pm_state;
+
+ spin_lock_irqsave(&ioapic_lock, flags);
+ for (apic = 0; apic < nr_ioapics; apic++){
+ reg_00.raw = io_apic_read(apic, 0);
+ if (reg_00.bits.ID != mp_ioapics[apic].mpc_apicid) {
+ reg_00.bits.ID = mp_ioapics[apic].mpc_apicid;
+ io_apic_write(apic, 0, reg_00.raw);
+ }
+ for (i = 0; i < nr_ioapic_registers[apic]; i ++, entry ++ ) {
+ io_apic_write(apic, 0x11+2*i, *(((int *)entry)+1));
+ io_apic_...
2013 Mar 19
7
[PATCH 0/3] IOMMU errata treatment adjustments
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
2008 Nov 13
69
[PATCH 00 of 38] xen: add more Xen dom0 support
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