1. 15 4月, 2015 1 次提交
  2. 03 5月, 2013 1 次提交
    • K
      x86, gdt, hibernate: Store/load GDT for hibernate path. · cc456c4e
      Konrad Rzeszutek Wilk 提交于
      The git commite7a5cd06
      ("x86-64, gdt: Store/load GDT for ACPI S3 or hibernate/resume path
      is not needed.") assumes that for the hibernate path the booting
      kernel and the resuming kernel MUST be the same. That is certainly
      the case for a 32-bit kernel (see check_image_kernel and
      CONFIG_ARCH_HIBERNATION_HEADER config option).
      
      However for 64-bit kernels it is OK to have a different kernel
      version (and size of the image) of the booting and resuming kernels.
      Hence the above mentioned git commit introduces an regression.
      
      This patch fixes it by introducing a 'struct desc_ptr gdt_desc'
      back in the 'struct saved_context'. However instead of having in the
      'save_processor_state' and 'restore_processor_state' the
      store/load_gdt calls, we are only saving the GDT in the
      save_processor_state.
      
      For the restore path the lgdt operation is done in
      hibernate_asm_[32|64].S in the 'restore_registers' path.
      
      The apt reader of this description will recognize that only 64-bit
      kernels need this treatment, not 32-bit. This patch adds the logic
      in the 32-bit path to be more similar to 64-bit so that in the future
      the unification process can take advantage of this.
      
      [ hpa: this also reverts an inadvertent on-disk format change ]
      Suggested-by: N"H. Peter Anvin" <hpa@zytor.com>
      Acked-by: N"Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Link: http://lkml.kernel.org/r/1367459610-9656-2-git-send-email-konrad.wilk@oracle.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      cc456c4e
  3. 14 2月, 2009 1 次提交
  4. 19 2月, 2008 1 次提交
  5. 10 2月, 2008 1 次提交
  6. 30 1月, 2008 1 次提交
  7. 24 10月, 2007 1 次提交
  8. 19 10月, 2007 2 次提交
    • R
      Hibernation: Pass CR3 in the image header on x86_64 · c30bb68c
      Rafael J. Wysocki 提交于
      Since we already pass the address of restore_registers() in the image header,
      we can also pass the value of the CR3 register from before the hibernation in
      the same way.  This will allow us to avoid using init_level4_pgt page tables
      during the restore.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c30bb68c
    • R
      Hibernation: Arbitrary boot kernel support on x86_64 · d158cbdf
      Rafael J. Wysocki 提交于
      Make it possible to restore a hibernation image on x86_64 with the help of a
      kernel different from the one in the image.
      
      The idea is to split the core restoration code into two separate parts and to
      place each of them in a different page.   The first part belongs to the boot
      kernel and is executed as the last step of the image kernel's memory
      restoration procedure.   Before being executed, it is relocated to a safe page
      that won't be overwritten while copying the image kernel pages.
      
      The final operation performed by it is a jump to the second part of the core
      restoration code that belongs to the image kernel and has just been restored.
      This code makes the CPU switch to the image kernel's page tables and restores
      the state of general purpose registers (including the stack pointer) from
      before the hibernation.
      
      The main issue with this idea is that in order to jump to the second part of
      the core restoration code the boot kernel needs to know its address.
       However, this address may be passed to it in the image header.   Namely, the
      part of the image header previously used for checking if the version of the
      image kernel is correct can be replaced with some architecture specific data
      that will allow the boot kernel to jump to the right address within the image
      kernel.   These data should also be used for checking if the image kernel is
      compatible with the boot kernel (as far as the memory restroration procedure
      is concerned).  It can be done, for example, with the help of a "magic" value
      that has to be equal in both kernels, so that they can be regarded as
      compatible.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d158cbdf
  9. 11 10月, 2007 2 次提交
  10. 03 5月, 2007 1 次提交
    • V
      [PATCH] x86-64: Relocatable Kernel Support · 1ab60e0f
      Vivek Goyal 提交于
      This patch modifies the x86_64 kernel so that it can be loaded and run
      at any 2M aligned address, below 512G.  The technique used is to
      compile the decompressor with -fPIC and modify it so the decompressor
      is fully relocatable.  For the main kernel the page tables are
      modified so the kernel remains at the same virtual address.  In
      addition a variable phys_base is kept that holds the physical address
      the kernel is loaded at.  __pa_symbol is modified to add that when
      we take the address of a kernel symbol.
      
      When loaded with a normal bootloader the decompressor will decompress
      the kernel to 2M and it will run there.  This both ensures the
      relocation code is always working, and makes it easier to use 2M
      pages for the kernel and the cpu.
      
      AK: changed to not make RELOCATABLE default in Kconfig
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      1ab60e0f
  11. 26 9月, 2006 1 次提交
  12. 10 10月, 2005 1 次提交
    • R
      [PATCH] x86_64: Set up safe page tables during resume · 3dd08325
      Rafael J. Wysocki 提交于
      The following patch makes swsusp avoid the possible temporary corruption
      of page translation tables during resume on x86-64.  This is achieved by
      creating a copy of the relevant page tables that will not be modified by
      swsusp and can be safely used by it on resume.
      
      The problem is that during resume on x86-64 swsusp may temporarily
      corrupt the page tables used for the direct mapping of RAM.  If that
      happens, a page fault occurs and cannot be handled properly, which leads
      to the solid hang of the affected system.  This leads to the loss of the
      system's state from before suspend and may result in the loss of data or
      the corruption of filesystems, so it is a serious issue.  Also, it
      appears to happen quite often (for me, as often as 50% of the time).
      
      The problem is related to the fact that (at least) one of the PMD
      entries used in the direct memory mapping (starting at PAGE_OFFSET)
      points to a page table the physical address of which is much greater
      than the physical address of the PMD entry itself.  Moreover,
      unfortunately, the physical address of the page table before suspend
      (i.e.  the one stored in the suspend image) happens to be different to
      the physical address of the corresponding page table used during resume
      (i.e.  the one that is valid right before swsusp_arch_resume() in
      arch/x86_64/kernel/suspend_asm.S is executed).  Thus while the image is
      restored, the "offending" PMD entry gets overwritten, so it does not
      point to the right physical address any more (i.e.  there's no page
      table at the address pointed to by it, because it points to the address
      the page table has been at during suspend).  Consequently, if the PMD
      entry is used later on, and it _is_ used in the process of copying the
      image pages, a page fault occurs, but it cannot be handled in the normal
      way and the system hangs.
      
      In principle we can call create_resume_mapping() from
      swsusp_arch_resume() (ie.  from suspend_asm.S), but then the memory
      allocations in create_resume_mapping(), resume_pud_mapping(), and
      resume_pmd_mapping() must be made carefully so that we use _only_
      NosaveFree pages in them (the other pages are overwritten by the loop in
      swsusp_arch_resume()).  Additionally, we are in atomic context at that
      time, so we cannot use GFP_KERNEL.  Moreover, if one of the allocations
      fails, we should free all of the allocated pages, so we need to trace
      them somehow.
      
      All of this is done in the appended patch, except that the functions
      populating the page tables are located in arch/x86_64/kernel/suspend.c
      rather than in init.c.  It may be done in a more elegan way in the
      future, with the help of some swsusp patches that are in the works now.
      
      [AK: move some externs into headers, renamed a function]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3dd08325
  13. 10 9月, 2005 1 次提交
  14. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4