Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 22 5月, 2015 2 次提交
  3. 05 2月, 2015 1 次提交
  5. 03 9月, 2014 1 次提交
  7. 31 7月, 2014 1 次提交
  9. 17 6月, 2014 1 次提交
    • L
      ACPICA: Restore error table definitions to reduce code differences between... · 0a00fd5e
      由 Lv Zheng 提交于 
      ACPICA: Restore error table definitions to reduce code differences between Linux and ACPICA upstream.

The following commit has changed ACPICA table header definitions:

 Commit: 88f074f4
 Subject: ACPI, CPER: Update cper info

While such definitions are currently maintained in ACPICA. As the
modifications applying to the table definitions affect other OSPMs'
drivers, it is very difficult for ACPICA to initiate a process to
complete the merge. Thus this commit finally only leaves us divergences.

Revert such naming modifications to reduce the source code differecnes
between Linux and ACPICA upstream. No functional changes.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: Bob Moore <robert.moore@intel.com>
Cc: Chen, Gong <gong.chen@linux.intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0a00fd5e
  11. 07 5月, 2014 1 次提交
  13. 18 3月, 2014 1 次提交
  15. 27 2月, 2014 1 次提交
  17. 11 2月, 2014 1 次提交
  19. 14 1月, 2014 1 次提交
  21. 08 1月, 2014 1 次提交
  23. 22 10月, 2013 1 次提交
  25. 25 1月, 2013 1 次提交
  27. 10 1月, 2013 1 次提交
    • L
      ACPICA: Cleanup updated comments. · 75c8044f
      由 Lv Zheng 提交于 
      This is a cosmetic patch only. Comparison of the resulting binary showed
only line number differences.

This patch does not affect the generation of the Linux binary.
This patch decreases 558 lines of 20121018 divergence.diff.

This patch reduces the source code diff between Linux and ACPICA by
cleaning the comments that already have been updated in ACPICA.

There is no extra indentation done in this patch. Even the empty line
deletions and insertions are also splitted into another cleanup patch so
that this patch can be easily reviewed, and the binary differences can be
held to a lowest level.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      75c8044f
  29. 21 9月, 2012 2 次提交
  31. 17 7月, 2012 2 次提交
  33. 18 1月, 2012 1 次提交
  35. 17 1月, 2012 1 次提交
  37. 19 1月, 2011 1 次提交
  39. 02 11月, 2010 1 次提交
  41. 23 1月, 2010 1 次提交
  43. 29 8月, 2009 4 次提交
  45. 27 8月, 2009 1 次提交
  47. 04 4月, 2009 1 次提交
  49. 31 12月, 2008 1 次提交
  51. 23 10月, 2008 1 次提交
  53. 17 7月, 2008 2 次提交
  55. 24 4月, 2008 1 次提交
  57. 23 4月, 2008 3 次提交
  59. 22 10月, 2007 1 次提交
    • K
      Intel IOMMU: DMAR detection and parsing logic · 10e5247f
      由 Keshavamurthy, Anil S 提交于 
      This patch supports the upcomming Intel IOMMU hardware a.k.a.  Intel(R)
Virtualization Technology for Directed I/O Architecture and the hardware spec
for the same can be found here
http://www.intel.com/technology/virtualization/index.htm

FAQ! (questions from akpm, answers from ak)

> So...  what's all this code for?
>
> I assume that the intent here is to speed things up under Xen, etc?

Yes in some cases, but not this code.  That would be the Xen version of this
code that could potentially assign whole devices to guests.  I expect this to
be only useful in some special cases though because most hardware is not
virtualizable and you typically want an own instance for each guest.

Ok at some point KVM might implement this too; i likely would use this code
for this.

> Do we
> have any benchmark results to help us to decide whether a merge would be
> justified?

The main advantage for doing it in the normal kernel is not performance, but
more safety.  Broken devices won't be able to corrupt memory by doing random
DMA.

Unfortunately that doesn't work for graphics yet, for that need user space
interfaces for the X server are needed.

There are some potential performance benefits too:

- When you have a device that cannot address the complete address range an
  IOMMU can remap its memory instead of bounce buffering.  Remapping is likely
  cheaper than copying.

- The IOMMU can merge sg lists into a single virtual block.  This could
  potentially speed up SG IO when the device is slow walking SG lists.  [I
  long ago benchmarked 5% on some block benchmark with an old MPT Fusion; but
  it probably depends a lot on the HBA]

And you get better driver debugging because unexpected memory accesses from
the devices will cause a trappable event.

>
> Does it slow anything down?

It adds more overhead to each IO so yes.

This patch:

Add support for early detection and parsing of DMAR's (DMA Remapping) reported
to OS via ACPI tables.

DMA remapping(DMAR) devices support enables independent address translations
for Direct Memory Access(DMA) from Devices.  These DMA remapping devices are
reported via ACPI tables and includes pci device scope covered by these DMA
remapping device.

For detailed info on the specification of "Intel(R) Virtualization Technology
for Directed I/O Architecture" please see
http://www.intel.com/technology/virtualization/index.htmSigned-off-by: NAnil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Greg KH <greg@kroah.com>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      10e5247f
  61. 03 2月, 2007 1 次提交