1. 30 Aug, 2013 3 commits
  2. 20 Aug, 2013 7 commits
    • Vaughan Cao's avatar
      xen/pvhvm: Initialize xen panic handler for PVHVM guests · 669b0ae9
      Vaughan Cao authored
      kernel use callback linked in panic_notifier_list to notice others when panic
      happens.
      NORET_TYPE void panic(const char * fmt, ...){
          ...
          atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
      }
      When Xen becomes aware of this, it will call xen_reboot(SHUTDOWN_crash) to
      send out an event with reason code - SHUTDOWN_crash.
      
      xen_panic_handler_init() is defined to register on panic_notifier_list but
      we only call it in xen_arch_setup which only be called by PV, this patch is
      necessary for PVHVM.
      
      Without this patch, setting 'on_crash=coredump-restart' in PVHVM guest config
      file won't lead a vmcore to be generate when the guest panics. It can be
      reproduced with 'echo c > /proc/sysrq-trigger'.
      Signed-off-by: default avatarVaughan Cao <vaughan.cao@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarJoe Jin <joe.jin@oracle.com>
      669b0ae9
    • Stefano Stabellini's avatar
      xen/m2p: use GNTTABOP_unmap_and_replace to reinstate the original mapping · ee072640
      Stefano Stabellini authored
      GNTTABOP_unmap_grant_ref unmaps a grant and replaces it with a 0
      mapping instead of reinstating the original mapping.
      Doing so separately would be racy.
      
      To unmap a grant and reinstate the original mapping atomically we use
      GNTTABOP_unmap_and_replace.
      GNTTABOP_unmap_and_replace doesn't work with GNTMAP_contains_pte, so
      don't use it for kmaps.  GNTTABOP_unmap_and_replace zeroes the mapping
      passed in new_addr so we have to reinstate it, however that is a
      per-cpu mapping only used for balloon scratch pages, so we can be sure that
      it's not going to be accessed while the mapping is not valid.
      Signed-off-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Reviewed-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      CC: alex@alex.org.uk
      CC: dcrisan@flexiant.com
      
      [v1: Konrad fixed up the conflicts]
      Conflicts:
      	arch/x86/xen/p2m.c
      ee072640
    • Stefano Stabellini's avatar
      xen: fix ARM build after 6efa20e4 · 072b2064
      Stefano Stabellini authored
      The following commit:
      
      commit 6efa20e4
      Author: Konrad Rzeszutek Wilk <konrad@kernel.org>
      Date:   Fri Jul 19 11:51:31 2013 -0400
      
          xen: Support 64-bit PV guest receiving NMIs
      
      breaks the Xen ARM build:
      
      CC      drivers/xen/events.o
      drivers/xen/events.c: In function 'xen_send_IPI_one':
      drivers/xen/events.c:1218:6: error: 'XEN_NMI_VECTOR' undeclared (first use in this function)
      
      Simply ifdef the undeclared symbol in the code.
      Signed-off-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      072b2064
    • Konrad Rzeszutek Wilk's avatar
      MAINTAINERS: Remove Jeremy from the Xen subsystem. · c65a8370
      Konrad Rzeszutek Wilk authored
      Jeremy has been a key person in making Linux work with Xen.
      He has been enjoying the last year working on something
      different so reflect that in the maintainers file.
      
      CC: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarJeremy Fitzhardinge <jeremy@goop.org>
      c65a8370
    • David Vrabel's avatar
      xen/events: document behaviour when scanning the start word for events · 3ef0296a
      David Vrabel authored
      The original comment on the scanning of the start word on the 2nd pass
      did not reflect the actual behaviour (the code was incorrectly masking
      bit_idx instead of the pending word itself).
      
      The documented behaviour is not actually required since if event were
      pending in the MSBs, they would be immediately scanned anyway as we go
      through the loop again.
      
      Update the documentation to reflect this (instead of trying to change
      the behaviour).
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      3ef0296a
    • David Vrabel's avatar
      x86/xen: during early setup, only 1:1 map the ISA region · e201bfcc
      David Vrabel authored
      During early setup, when the reserved regions and MMIO holes are being
      setup as 1:1 in the p2m, clear any mappings instead of making them 1:1
      (execept for the ISA region which is expected to be mapped).
      
      This fixes a regression introduced in 3.5 by 83d51ab4 (xen/setup:
      update VA mapping when releasing memory during setup) which caused
      hosts with tboot to fail to boot.
      
      tboot marks a region in the e820 map as unusable and the dom0 kernel
      would attempt to map this region and Xen does not permit unusable
      regions to be mapped by guests.
      
      (XEN)  0000000000000000 - 0000000000060000 (usable)
      (XEN)  0000000000060000 - 0000000000068000 (reserved)
      (XEN)  0000000000068000 - 000000000009e000 (usable)
      (XEN)  0000000000100000 - 0000000000800000 (usable)
      (XEN)  0000000000800000 - 0000000000972000 (unusable)
      
      tboot marked this region as unusable.
      
      (XEN)  0000000000972000 - 00000000cf200000 (usable)
      (XEN)  00000000cf200000 - 00000000cf38f000 (reserved)
      (XEN)  00000000cf38f000 - 00000000cf3ce000 (ACPI data)
      (XEN)  00000000cf3ce000 - 00000000d0000000 (reserved)
      (XEN)  00000000e0000000 - 00000000f0000000 (reserved)
      (XEN)  00000000fe000000 - 0000000100000000 (reserved)
      (XEN)  0000000100000000 - 0000000630000000 (usable)
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      e201bfcc
    • David Vrabel's avatar
      x86/xen: disable premption when enabling local irqs · fb58e300
      David Vrabel authored
      If CONFIG_PREEMPT is enabled then xen_enable_irq() (and
      xen_restore_fl()) could be preempted and rescheduled on a different
      VCPU in between the clear of the mask and the check for pending
      events.  This may result in events being lost as the upcall will check
      for pending events on the wrong VCPU.
      
      Fix this by disabling preemption around the unmask and check for
      events.
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      fb58e300
  3. 09 Aug, 2013 11 commits
  4. 04 Aug, 2013 6 commits
  5. 03 Aug, 2013 13 commits