1. 08 7月, 2011 1 次提交
  2. 30 6月, 2011 2 次提交
    • K
      xen/pci: Use the INT_SRC_OVR IRQ (instead of GSI) to preset the ACPI SCI IRQ. · 155a16f2
      Konrad Rzeszutek Wilk 提交于
      In the past we would use the GSI value to preset the ACPI SCI
      IRQ which worked great as GSI == IRQ:
      
      ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
      
      While that is most often seen, there are some oddities:
      
      ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
      
      which means that GSI 20 (or pin 20) is to be overriden for IRQ 9.
      Our code that presets the interrupt for ACPI SCI however would
      use the GSI 20 instead of IRQ 9 ending up with:
      
      xen: sci override: global_irq=20 trigger=0 polarity=1
      xen: registering gsi 20 triggering 0 polarity 1
      xen: --> pirq=20 -> irq=20
      xen: acpi sci 20
      .. snip..
      calling  acpi_init+0x0/0xbc @ 1
      ACPI: SCI (IRQ9) allocation failed
      ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20110413/evevent-119)
      ACPI: Unable to start the ACPI Interpreter
      
      as the ACPI interpreter made a call to 'acpi_gsi_to_irq' which got nine.
      It used that value to request an IRQ (request_irq) and since that was not
      present it failed.
      
      The fix is to recognize that for interrupts that are overriden (in our
      case we only care about the ACPI SCI) we should use the IRQ number
      to present the IRQ instead of the using GSI. End result is that we get:
      
      xen: sci override: global_irq=20 trigger=0 polarity=1
      xen: registering gsi 20 triggering 0 polarity 1
      xen: --> pirq=20 -> irq=9 (gsi=9)
      xen: acpi sci 9
      
      which fixes the ACPI interpreter failing on startup.
      
      CC: stable@kernel.org
      Reported-by: NLiwei <xieliwei@gmail.com>
      Tested-by: NLiwei <xieliwei@gmail.com>
      [http://lists.xensource.com/archives/html/xen-devel/2011-06/msg01727.html]
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      155a16f2
    • K
      xen/mmu: Fix for linker errors when CONFIG_SMP is not defined. · 32dd1194
      Konrad Rzeszutek Wilk 提交于
      Simple enough - we use an extern defined symbol which is not
      defined when CONFIG_SMP is not defined. This fixes the linker
      dying.
      
      CC: stable@kernel.org
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      32dd1194
  3. 17 6月, 2011 1 次提交
    • K
      xen/setup: Fix for incorrect xen_extra_mem_start. · acd049c6
      Konrad Rzeszutek Wilk 提交于
      The earlier attempts (24bdb0b6)
      at fixing this problem caused other problems to surface (PV guests
      with no PCI passthrough would have SWIOTLB turned on - which meant
      64MB of precious contingous DMA32 memory being eaten up per guest).
      The problem was: "on xen we add an extra memory region at the end of
      the e820, and on this particular machine this extra memory region
      would start below 4g and cross over the 4g boundary:
      
      [0xfee01000-0x192655000)
      
      Unfortunately e820_end_of_low_ram_pfn does not expect an
      e820 layout like that so it returns 4g, therefore initial_memory_mapping
      will map [0 - 0x100000000), that is a memory range that includes some
      reserved memory regions."
      
      The memory range was the IOAPIC regions, and with the 1-1 mapping
      turned on, it would map them as RAM, not as MMIO regions. This caused
      the hypervisor to complain. Fortunately this is experienced only under
      the initial domain so we guard for it.
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      acd049c6
  4. 16 6月, 2011 3 次提交
  5. 09 6月, 2011 1 次提交
  6. 04 6月, 2011 1 次提交
  7. 31 5月, 2011 1 次提交
  8. 30 5月, 2011 30 次提交