1. 29 10月, 2013 1 次提交
  2. 05 10月, 2013 1 次提交
  3. 05 9月, 2013 2 次提交
  4. 01 8月, 2013 1 次提交
  5. 15 7月, 2013 1 次提交
    • P
      x86: delete __cpuinit usage from all x86 files · 148f9bb8
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      are flagged as __cpuinit  -- so if we remove the __cpuinit from
      arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      content into no-ops as early as possible, since that will get rid
      of these warnings.  In any case, they are temporary and harmless.
      
      This removes all the arch/x86 uses of the __cpuinit macros from
      all C files.  x86 only had the one __CPUINIT used in assembly files,
      and it wasn't paired off with a .previous or a __FINIT, so we can
      delete it directly w/o any corresponding additional change there.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      148f9bb8
  6. 12 7月, 2013 1 次提交
  7. 11 7月, 2013 1 次提交
  8. 21 6月, 2013 1 次提交
  9. 11 6月, 2013 1 次提交
    • M
      Modify UEFI anti-bricking code · f8b84043
      Matthew Garrett 提交于
      This patch reworks the UEFI anti-bricking code, including an effective
      reversion of cc5a080c and 31ff2f20. It turns out that calling
      QueryVariableInfo() from boot services results in some firmware
      implementations jumping to physical addresses even after entering virtual
      mode, so until we have 1:1 mappings for UEFI runtime space this isn't
      going to work so well.
      
      Reverting these gets us back to the situation where we'd refuse to create
      variables on some systems because they classify deleted variables as "used"
      until the firmware triggers a garbage collection run, which they won't do
      until they reach a lower threshold. This results in it being impossible to
      install a bootloader, which is unhelpful.
      
      Feedback from Samsung indicates that the firmware doesn't need more than
      5KB of storage space for its own purposes, so that seems like a reasonable
      threshold. However, there's still no guarantee that a platform will attempt
      garbage collection merely because it drops below this threshold. It seems
      that this is often only triggered if an attempt to write generates a
      genuine EFI_OUT_OF_RESOURCES error. We can force that by attempting to
      create a variable larger than the remaining space. This should fail, but if
      it somehow succeeds we can then immediately delete it.
      
      I've tested this on the UEFI machines I have available, but I don't have
      a Samsung and so can't verify that it avoids the bricking problem.
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: Lee, Chun-Y <jlee@suse.com> [ dummy variable cleanup ]
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      f8b84043
  10. 06 6月, 2013 1 次提交
  11. 30 5月, 2013 1 次提交
  12. 29 5月, 2013 1 次提交
    • D
      x86: Increase precision of x86_platform.get/set_wallclock() · 3565184e
      David Vrabel 提交于
      All the virtualized platforms (KVM, lguest and Xen) have persistent
      wallclocks that have more than one second of precision.
      
      read_persistent_wallclock() and update_persistent_wallclock() allow
      for nanosecond precision but their implementation on x86 with
      x86_platform.get/set_wallclock() only allows for one second precision.
      This means guests may see a wallclock time that is off by up to 1
      second.
      
      Make set_wallclock() and get_wallclock() take a struct timespec
      parameter (which allows for nanosecond precision) so KVM and Xen
      guests may start with a more accurate wallclock time and a Xen dom0
      can maintain a more accurate wallclock for guests.
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      3565184e
  13. 14 5月, 2013 1 次提交
    • L
      x86, efi: initial the local variable of DataSize to zero · eccaf52f
      Lee, Chun-Yi 提交于
      That will be better initial the value of DataSize to zero for the input of
      GetVariable(), otherwise we will feed a random value. The debug log of input
      DataSize like this:
      
      ...
      [  195.915612] EFI Variables Facility v0.08 2004-May-17
      [  195.915819] efi: size: 18446744071581821342
      [  195.915969] efi:  size': 18446744071581821342
      [  195.916324] efi: size: 18446612150714306560
      [  195.916632] efi:  size': 18446612150714306560
      [  195.917159] efi: size: 18446612150714306560
      [  195.917453] efi:  size': 18446612150714306560
      ...
      
      The size' is value that was returned by BIOS.
      
      After applied this patch:
      [   82.442042] EFI Variables Facility v0.08 2004-May-17
      [   82.442202] efi: size: 0
      [   82.442360] efi:  size': 1039
      [   82.443828] efi: size: 0
      [   82.444127] efi:  size': 2616
      [   82.447057] efi: size: 0
      [   82.447356] efi:  size': 5832
      ...
      
      Found on Acer Aspire V3 BIOS, it will not return the size of data if we input a
      non-zero DataSize.
      
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NLee, Chun-Yi <jlee@suse.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      eccaf52f
  14. 30 4月, 2013 1 次提交
  15. 24 4月, 2013 1 次提交
  16. 17 4月, 2013 2 次提交
  17. 16 4月, 2013 2 次提交
    • M
      efi: Distinguish between "remaining space" and actually used space · 31ff2f20
      Matthew Garrett 提交于
      EFI implementations distinguish between space that is actively used by a
      variable and space that merely hasn't been garbage collected yet. Space
      that hasn't yet been garbage collected isn't available for use and so isn't
      counted in the remaining_space field returned by QueryVariableInfo().
      
      Combined with commit 68d92986 this can cause problems. Some implementations
      don't garbage collect until the remaining space is smaller than the maximum
      variable size, and as a result check_var_size() will always fail once more
      than 50% of the variable store has been used even if most of that space is
      marked as available for garbage collection. The user is unable to create
      new variables, and deleting variables doesn't increase the remaining space.
      
      The problem that 68d92986 was attempting to avoid was one where certain
      platforms fail if the actively used space is greater than 50% of the
      available storage space. We should be able to calculate that by simply
      summing the size of each available variable and subtracting that from
      the total storage space. With luck this will fix the problem described in
      https://bugzilla.kernel.org/show_bug.cgi?id=55471 without permitting
      damage to occur to the machines 68d92986 was attempting to fix.
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      31ff2f20
    • M
      efi: Pass boot services variable info to runtime code · cc5a080c
      Matthew Garrett 提交于
      EFI variables can be flagged as being accessible only within boot services.
      This makes it awkward for us to figure out how much space they use at
      runtime. In theory we could figure this out by simply comparing the results
      from QueryVariableInfo() to the space used by all of our variables, but
      that fails if the platform doesn't garbage collect on every boot. Thankfully,
      calling QueryVariableInfo() while still inside boot services gives a more
      reliable answer. This patch passes that information from the EFI boot stub
      up to the efi platform code.
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      cc5a080c
  18. 11 4月, 2013 1 次提交
  19. 09 4月, 2013 1 次提交
    • M
      x86, efivars: firmware bug workarounds should be in platform code · a6e4d5a0
      Matt Fleming 提交于
      Let's not burden ia64 with checks in the common efivars code that we're not
      writing too much data to the variable store. That kind of thing is an x86
      firmware bug, plain and simple.
      
      efi_query_variable_store() provides platforms with a wrapper in which they can
      perform checks and workarounds for EFI variable storage bugs.
      
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      a6e4d5a0
  20. 16 3月, 2013 1 次提交
    • P
      x86: Do full rtc synchronization with ntp · 3195ef59
      Prarit Bhargava 提交于
      Every 11 minutes ntp attempts to update the x86 rtc with the current
      system time.  Currently, the x86 code only updates the rtc if the system
      time is within +/-15 minutes of the current value of the rtc. This
      was done originally to avoid setting the RTC if the RTC was in localtime
      mode (common with Windows dualbooting).  Other architectures do a full
      synchronization and now that we have better infrastructure to detect
      when the RTC is in localtime, there is no reason that x86 should be
      software limited to a 30 minute window.
      
      This patch changes the behavior of the kernel to do a full synchronization
      (year, month, day, hour, minute, and second) of the rtc when ntp requests
      a synchronization between the system time and the rtc.
      
      I've used the RTC library functions in this patchset as they do all the
      required bounds checking.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: x86@kernel.org
      Cc: Matt Fleming <matt.fleming@intel.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: linux-efi@vger.kernel.org
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      [jstultz: Tweak commit message, fold in build fix found by fengguang
      Also add select RTC_LIB to X86, per new dependency, as found by prarit]
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      3195ef59
  21. 12 3月, 2013 1 次提交
  22. 11 3月, 2013 1 次提交
  23. 04 3月, 2013 1 次提交
  24. 26 2月, 2013 1 次提交
  25. 21 2月, 2013 1 次提交
  26. 14 2月, 2013 2 次提交
  27. 12 2月, 2013 1 次提交
  28. 31 1月, 2013 1 次提交
    • M
      efi: Make 'efi_enabled' a function to query EFI facilities · 83e68189
      Matt Fleming 提交于
      Originally 'efi_enabled' indicated whether a kernel was booted from
      EFI firmware. Over time its semantics have changed, and it now
      indicates whether or not we are booted on an EFI machine with
      bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
      
      The immediate motivation for this patch is the bug report at,
      
          https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
      
      which details how running a platform driver on an EFI machine that is
      designed to run under BIOS can cause the machine to become
      bricked. Also, the following report,
      
          https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
      details how running said driver can also cause Machine Check
      Exceptions. Drivers need a new means of detecting whether they're
      running on an EFI machine, as sadly the expression,
      
          if (!efi_enabled)
      
      hasn't been a sufficient condition for quite some time.
      
      Users actually want to query 'efi_enabled' for different reasons -
      what they really want access to is the list of available EFI
      facilities.
      
      For instance, the x86 reboot code needs to know whether it can invoke
      the ResetSystem() function provided by the EFI runtime services, while
      the ACPI OSL code wants to know whether the EFI config tables were
      mapped successfully. There are also checks in some of the platform
      driver code to simply see if they're running on an EFI machine (which
      would make it a bad idea to do BIOS-y things).
      
      This patch is a prereq for the samsung-laptop fix patch.
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      83e68189
  29. 26 1月, 2013 2 次提交
  30. 25 1月, 2013 3 次提交
  31. 24 1月, 2013 1 次提交
  32. 22 1月, 2013 1 次提交
  33. 18 1月, 2013 1 次提交
    • N
      efi, x86: Pass a proper identity mapping in efi_call_phys_prelog · b8f2c21d
      Nathan Zimmer 提交于
      Update efi_call_phys_prelog to install an identity mapping of all available
      memory.  This corrects a bug on very large systems with more then 512 GB in
      which bios would not be able to access addresses above not in the mapping.
      
      The result is a crash that looks much like this.
      
      BUG: unable to handle kernel paging request at 000000effd870020
      IP: [<0000000078bce331>] 0x78bce330
      PGD 0
      Oops: 0000 [#1] SMP
      Modules linked in:
      CPU 0
      Pid: 0, comm: swapper/0 Tainted: G        W    3.8.0-rc1-next-20121224-medusa_ntz+ #2 Intel Corp. Stoutland Platform
      RIP: 0010:[<0000000078bce331>]  [<0000000078bce331>] 0x78bce330
      RSP: 0000:ffffffff81601d28  EFLAGS: 00010006
      RAX: 0000000078b80e18 RBX: 0000000000000004 RCX: 0000000000000004
      RDX: 0000000078bcf958 RSI: 0000000000002400 RDI: 8000000000000000
      RBP: 0000000078bcf760 R08: 000000effd870000 R09: 0000000000000000
      R10: 0000000000000000 R11: 00000000000000c3 R12: 0000000000000030
      R13: 000000effd870000 R14: 0000000000000000 R15: ffff88effd870000
      FS:  0000000000000000(0000) GS:ffff88effe400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000effd870020 CR3: 000000000160c000 CR4: 00000000000006b0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process swapper/0 (pid: 0, threadinfo ffffffff81600000, task ffffffff81614400)
      Stack:
       0000000078b80d18 0000000000000004 0000000078bced7b ffff880078b81fff
       0000000000000000 0000000000000082 0000000078bce3a8 0000000000002400
       0000000060000202 0000000078b80da0 0000000078bce45d ffffffff8107cb5a
      Call Trace:
       [<ffffffff8107cb5a>] ? on_each_cpu+0x77/0x83
       [<ffffffff8102f4eb>] ? change_page_attr_set_clr+0x32f/0x3ed
       [<ffffffff81035946>] ? efi_call4+0x46/0x80
       [<ffffffff816c5abb>] ? efi_enter_virtual_mode+0x1f5/0x305
       [<ffffffff816aeb24>] ? start_kernel+0x34a/0x3d2
       [<ffffffff816ae5ed>] ? repair_env_string+0x60/0x60
       [<ffffffff816ae2be>] ? x86_64_start_reservations+0xba/0xc1
       [<ffffffff816ae120>] ? early_idt_handlers+0x120/0x120
       [<ffffffff816ae419>] ? x86_64_start_kernel+0x154/0x163
      Code:  Bad RIP value.
      RIP  [<0000000078bce331>] 0x78bce330
       RSP <ffffffff81601d28>
      CR2: 000000effd870020
      ---[ end trace ead828934fef5eab ]---
      
      Cc: stable@vger.kernel.org
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NNathan Zimmer <nzimmer@sgi.com>
      Signed-off-by: NRobin Holt <holt@sgi.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      b8f2c21d