Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
11 个月 前同步成功

通知 150
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 25 3月, 2015 1 次提交
  3. 03 3月, 2015 1 次提交
    • Q
      iommu/vt-d: Convert non-returned local variable to boolean when relevant · 2f119c78
      由 Quentin Lambert 提交于 
      This patch was produced using Coccinelle. A simplified version of the
semantic patch is:

@r exists@
identifier f;
local idexpression u8 x;
identifier xname;
@@

f(...) {
...when any
(
  x@xname = 1;
|
  x@xname = 0;
)
...when any
}

@bad exists@
identifier r.f;
local idexpression u8 r.x
expression e1 != {0, 1}, e2;
@@

f(...) {
...when any
(
  x = e1;
|
  x + e2
)
...when any
}

@depends on !bad@
identifier r.f;
local idexpression u8 r.x;
identifier r.xname;
@@

f(...) {
...
++ bool xname;
- int xname;
<...
(
  x =
- 1
+ true
|
  x =
- -1
+ false
)
...>

}
Signed-off-by: NQuentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      2f119c78
  5. 15 1月, 2015 7 次提交
  7. 16 12月, 2014 1 次提交
  9. 18 11月, 2014 3 次提交
  11. 26 9月, 2014 1 次提交
    • Y
      iommu/irq_remapping: Fix the regression of hpet irq remapping · 5fc24d8c
      由 Yijing Wang 提交于 
      Commit 71054d88 ("x86, hpet: Introduce x86_msi_ops.setup_hpet_msi")
introduced x86_msi_ops.setup_hpet_msi to setup hpet MSI irq
when irq remapping enabled. This caused a regression of
hpet MSI irq remapping.

Original code flow before commit 71054d88:
hpet_setup_msi_irq()
	arch_setup_hpet_msi()
		setup_hpet_msi_remapped()
			remap_ops->setup_hpet_msi()
				alloc_irte()
		msi_compose_msg()
		hpet_msi_write()
		...

Current code flow after commit 71054d88:
hpet_setup_msi_irq()
	x86_msi.setup_hpet_msi()
		setup_hpet_msi_remapped()
			intel_setup_hpet_msi()
				alloc_irte()

Currently, we only call alloc_irte() for hpet MSI, but
do not composed and wrote its msg...
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      5fc24d8c
  13. 19 8月, 2014 1 次提交
  15. 31 7月, 2014 1 次提交
    • G
      iommu/vt-d: Fix race setting IRQ CPU affinity while freeing IRQ · af437469
      由 Greg Edwards 提交于 
      A user process setting the CPU affinity of an IRQ for a KVM
direct-assigned device via /proc/irq/<IRQ#>/smp_affinity can race with
the IRQ being released by QEMU, resulting in a NULL iommu pointer
dereference in get_irte(), causing this crash:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000090
 IP: [<ffffffff8190a652>] intel_ioapic_set_affinity+0x82/0x1b0
 PGD 99172e067 PUD 1026979067 PMD 0
 Oops: 0000 [#1] SMP
 Modules linked in:
 CPU: 1 PID: 3354 Comm: affin Not tainted 3.16.0-rc7-00007-g31dab719 #1
 Hardware name: Supermicro SYS-F617R2-RT+/X9DRFR, BIOS 3.0a 01/29/2014
 task: ffff881025b0e720 ti: ffff88099173c000 task.ti: ffff88099173c000
 RIP: 0010:[<ffffffff8190a652>]  [<ffffffff8190a652>] intel_ioapic_set_affinity+0x82/0x1b0
 RSP: 0018:ffff88099173fdb0  EFLAGS: 00010046
 RAX: 0000000000000082 RBX: ffff880a36294600 RCX: 0000000000000082
 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8266af00
 RBP: ffff88099173fdf8 R08: 0000000000000000 R09: ffff88103ec00490
 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88099173fe90
 R13: 000000000000005f R14: ffff880faa38fe80 R15: ffff880faa38fe80
 FS:  00007f7161f05740(0000) GS:ffff88107fc40000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000090 CR3: 000000099140d000 CR4: 00000000001427e0
 Stack:
  ffffffff81c44740 ffff88099173fdc8 ffffffff00000000 00000000c991fd3b
  ffff880a36294600 ffff88099173fe90 ffff88099173fe90 0000000000000000
  0000000000000286 ffff88099173fe08 ffffffff8190aac5 ffff88099173fe28
 Call Trace:
  [<ffffffff8190aac5>] set_remapped_irq_affinity+0x25/0x40
  [<ffffffff811322dc>] irq_do_set_affinity+0x1c/0x50
  [<ffffffff81132458>] irq_set_affinity_locked+0x98/0xd0
  [<ffffffff811324d6>] __irq_set_affinity+0x46/0x70
  [<ffffffff811362dc>] write_irq_affinity.isra.6+0xdc/0x100
  [<ffffffff8113631c>] irq_affinity_list_proc_write+0x1c/0x20
  [<ffffffff8129f30d>] proc_reg_write+0x3d/0x80
  [<ffffffff812384a7>] vfs_write+0xb7/0x1f0
  [<ffffffff81243619>] ? putname+0x29/0x40
  [<ffffffff812390c5>] SyS_write+0x55/0xd0
  [<ffffffff81adc729>] system_call_fastpath+0x16/0x1b
 Code: ff 48 85 d2 74 68 4c 8b 7a 30 4d 85 ff 74 5f 48 c7 c7 00 af 66 82 e8 9e 1b 1d 00 49 8b 57 20 41 0f b7 77 28 48 c7 c7 00 af 66 82 <48> 8b 8a 90 00 00 00 41 0f b7 57 2a 01 f2 48 89 c6 48 63 d2 48
 RIP  [<ffffffff8190a652>] intel_ioapic_set_affinity+0x82/0x1b0
  RSP <ffff88099173fdb0>
 CR2: 0000000000000090
Signed-off-by: NGreg Edwards <gedwards@ddn.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      af437469
  17. 04 7月, 2014 1 次提交
    • A
      iommu/vt-d: Update to use PCI DMA aliases · 579305f7
      由 Alex Williamson 提交于 
      VT-d code currently makes use of pci_find_upstream_pcie_bridge() in
order to find the topology based alias of a device.  This function has
a few problems.  First, it doesn't check the entire alias path of the
device to the root bus, therefore if a PCIe device is masked upstream,
the wrong result is produced.  Also, it's known to get confused and
give up when it crosses a bridge from a conventional PCI bus to a PCIe
bus that lacks a PCIe capability.  The PCI-core provided DMA alias
support solves both of these problems and additionally adds support
for DMA function quirks allowing VT-d to work with devices like
Marvell and Ricoh with known broken requester IDs.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      579305f7
  19. 05 3月, 2014 1 次提交
    • J
      iommu/vt-d: Introduce a rwsem to protect global data structures · 3a5670e8
      由 Jiang Liu 提交于 
      Introduce a global rwsem dmar_global_lock, which will be used to
protect DMAR related global data structures from DMAR/PCI/memory
device hotplug operations in process context.

DMA and interrupt remapping related data structures are read most,
and only change when memory/PCI/DMAR hotplug event happens.
So a global rwsem solution is adopted for balance between simplicity
and performance.

For interrupt remapping driver, function intel_irq_remapping_supported(),
dmar_table_init(), intel_enable_irq_remapping(), disable_irq_remapping(),
reenable_irq_remapping() and enable_drhd_fault_handling() etc
are called during booting, suspending and resuming with interrupt
disabled, so no need to take the global lock.

For interrupt remapping entry allocation, the locking model is:
	down_read(&dmar_global_lock);
	/* Find corresponding iommu */
	iommu = map_hpet_to_ir(id);
	if (iommu)
		/*
		 * Allocate remapping entry and mark entry busy,
		 * the IOMMU won't be hot-removed until the
		 * allocated entry has been released.
		 */
		index = alloc_irte(iommu, irq, 1);
	up_read(&dmar_global_lock);

For DMA remmaping driver, we only uses the dmar_global_lock rwsem to
protect functions which are only called in process context. For any
function which may be called in interrupt context, we will use RCU
to protect them in following patches.
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      3a5670e8
  21. 09 1月, 2014 5 次提交
  23. 08 1月, 2014 1 次提交
    • J
      iommu/vt-d: use dedicated bitmap to track remapping entry allocation status · 360eb3c5
      由 Jiang Liu 提交于 
      Currently Intel interrupt remapping drivers uses the "present" flag bit
in remapping entry to track whether an entry is allocated or not.
It works as follow:
1) allocate a remapping entry and set its "present" flag bit to 1
2) compose other fields for the entry
3) update the remapping entry with the composed value

The remapping hardware may access the entry between step 1 and step 3,
which then observers an entry with the "present" flag set but random
values in all other fields.

This patch introduces a dedicated bitmap to track remapping entry
allocation status instead of sharing the "present" flag with hardware,
thus eliminate the race window. It also simplifies the implementation.
Tested-and-reviewed-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      360eb3c5
  25. 30 12月, 2013 1 次提交
  27. 07 12月, 2013 1 次提交
    • L
      ACPI: Clean up inclusions of ACPI header files · 8b48463f
      由 Lv Zheng 提交于 
      Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
<acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
inclusions and remove some inclusions of those files that aren't
necessary.

First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
should not be included directly from any files that are built for
CONFIG_ACPI unset, because that generally leads to build warnings about
undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
<linux/acpi.h> includes those files and for CONFIG_ACPI unset it
provides stub ACPI symbols to be used in that case.

Second, there are ordering dependencies between those files that always
have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
latter depends on are always there.  And <acpi/acpi.h> which provides
basic ACPICA type declarations should always be included prior to any other
ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
<linux/acpi.h> as appropriate.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8b48463f
  29. 31 10月, 2013 1 次提交
    • L
      ACPICA: Update DMAR table definitions. · fa5f508f
      由 Lv Zheng 提交于 
      This patch updates DMAR table header definitions as such enhancement
has been made in ACPICA upstream already.  It ports that change to
the Linux source to reduce source code differences between Linux and
ACPICA upstream.

Build test done on x86-64 machine with the following configs enabled:
  CONFIG_DMAR_TABLE
  CONFIG_IRQ_REMAP
  CONFIG_INTEL_IOMMU

This patch does not affect the generation of the Linux kernel binary.

[rjw: Changelog]
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fa5f508f
  31. 04 10月, 2013 1 次提交
    • N
      iommu: Remove stack trace from broken irq remapping warning · 05104a4e
      由 Neil Horman 提交于 
      The warning for the irq remapping broken check in intel_irq_remapping.c is
pretty pointless.  We need the warning, but we know where its comming from, the
stack trace will always be the same, and it needlessly triggers things like
Abrt.  This changes the warning to just print a text warning about BIOS being
broken, without the stack trace, then sets the appropriate taint bit.  Since we
automatically disable irq remapping, theres no need to contiue making Abrt jump
at this problem
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
CC: Joerg Roedel <joro@8bytes.org>
CC: Bjorn Helgaas <bhelgaas@google.com>
CC: Andy Lutomirski <luto@amacapital.net>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      05104a4e
  33. 20 6月, 2013 1 次提交
  35. 18 4月, 2013 1 次提交
    • N
      iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets · 03bbcb2e
      由 Neil Horman 提交于 
      A few years back intel published a spec update:
http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf

For the 5520 and 5500 chipsets which contained an errata (specificially errata
53), which noted that these chipsets can't properly do interrupt remapping, and
as a result the recommend that interrupt remapping be disabled in bios.  While
many vendors have a bios update to do exactly that, not all do, and of course
not all users update their bios to a level that corrects the problem.  As a
result, occasionally interrupts can arrive at a cpu even after affinity for that
interrupt has be moved, leading to lost or spurrious interrupts (usually
characterized by the message:
kernel: do_IRQ: 7.71 No irq handler for vector (irq -1)

There have been several incidents recently of people seeing this error, and
investigation has shown that they have system for which their BIOS level is such
that this feature was not properly turned off.  As such, it would be good to
give them a reminder that their systems are vulnurable to this problem.  For
details of those that reported the problem, please see:
https://bugzilla.redhat.com/show_bug.cgi?id=887006

[ Joerg: Removed CONFIG_IRQ_REMAP ifdef from early-quirks.c ]
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
CC: Prarit Bhargava <prarit@redhat.com>
CC: Don Zickus <dzickus@redhat.com>
CC: Don Dutile <ddutile@redhat.com>
CC: Bjorn Helgaas <bhelgaas@google.com>
CC: Asit Mallick <asit.k.mallick@intel.com>
CC: David Woodhouse <dwmw2@infradead.org>
CC: linux-pci@vger.kernel.org
CC: Joerg Roedel <joro@8bytes.org>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      03bbcb2e
  37. 03 2月, 2013 1 次提交
    • A
      x86/intel/irq_remapping: Clean up x2apic opt-out security warning mess · af8d102f
      由 Andy Lutomirski 提交于 
      Current kernels print this on my Dell server:

   ------------[ cut here ]------------
   WARNING: at drivers/iommu/intel_irq_remapping.c:542
   intel_enable_irq_remapping+0x7b/0x27e()
   Hardware name: PowerEdge R620
   Your BIOS is broken and requested that x2apic be disabled
   This will leave your machine vulnerable to irq-injection attacks
   Use 'intremap=no_x2apic_optout' to override BIOS request
   [...]
   Enabled IRQ remapping in xapic mode
   x2apic not enabled, IRQ remapping is in xapic mode

This is inconsistent with itself -- interrupt remapping is *on*.

Fix the mess by making the warnings say what they mean and my
making sure that compatibility format interrupts (the dangerous
ones) are disabled if x2apic is present regardless of BIOS
settings.

With this patch applied, the output is:

  Your BIOS is broken and requested that x2apic be disabled.
  This will slightly decrease performance.
  Use 'intremap=no_x2apic_optout' to override BIOS request.
  Enabled IRQ remapping in xapic mode
  x2apic not enabled, IRQ remapping is in xapic mode

This should make us as or more secure than we are now and
replace a rather scary warning with a much less scary warning on
silly but functional systems.
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Link: http://lkml.kernel.org/r/2011b943a886fd7c46079eb10bc24fc130587503.1359759303.git.luto@amacapital.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      af8d102f
  39. 28 1月, 2013 2 次提交
  41. 10 8月, 2012 1 次提交
  43. 15 6月, 2012 1 次提交
  45. 13 6月, 2012 1 次提交
  47. 08 6月, 2012 1 次提交
    • A
      x86/apic: Make cpu_mask_to_apicid() operations return error code · ff164324
      由 Alexander Gordeev 提交于 
      Current cpu_mask_to_apicid() and cpu_mask_to_apicid_and()
implementations have few shortcomings:

1. A value returned by cpu_mask_to_apicid() is written to
hardware registers unconditionally. Should BAD_APICID get ever
returned it will be written to a hardware too. But the value of
BAD_APICID is not universal across all hardware in all modes and
might cause unexpected results, i.e. interrupts might get routed
to CPUs that are not configured to receive it.

2. Because the value of BAD_APICID is not universal it is
counter- intuitive to return it for a hardware where it does not
make sense (i.e. x2apic).

3. cpu_mask_to_apicid_and() operation is thought as an
complement to cpu_mask_to_apicid() that only applies a AND mask
on top of a cpumask being passed. Yet, as consequence of 18374d89
commit the two operations are inconsistent in that of:
  cpu_mask_to_apicid() should not get a offline CPU with the cpumask
  cpu_mask_to_apicid_and() should not fail and return BAD_APICID
These limitations are impossible to realize just from looking at
the operations prototypes.

Most of these shortcomings are resolved by returning a error
code instead of BAD_APICID. As the result, faults are reported
back early rather than possibilities to cause a unexpected
behaviour exist (in case of [1]).

The only exception is setup_timer_IRQ0_pin() routine. Although
obviously controversial to this fix, its existing behaviour is
preserved to not break the fragile check_timer() and would
better addressed in a separate fix.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/20120607131559.GF4759@dhcp-26-207.brq.redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      ff164324
  49. 08 5月, 2012 2 次提交
  51. 07 5月, 2012 1 次提交