1. 15 Sep, 2011 2 commits
    • Jan Beulich's avatar
      xen/i386: follow-up to "replace order-based range checking of M2P table by linear one" · 61cca2fa
      Jan Beulich authored
      The numbers obtained from the hypervisor really can't ever lead to an
      overflow here, only the original calculation going through the order
      of the range could have. This avoids the (as Jeremy points outs)
      somewhat ugly NULL-based calculation here.
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      61cca2fa
    • Konrad Rzeszutek Wilk's avatar
      xen/irq: Alter the locking to use a mutex instead of a spinlock. · 77365948
      Konrad Rzeszutek Wilk authored
      When we allocate/change the IRQ informations, we do not
      need to use spinlocks. We can use a mutex (which is
      what the generic IRQ code does for allocations/changes).
      Fixes a slew of:
      
      BUG: sleeping function called from invalid context at /linux/kernel/mutex.c:271
      in_atomic(): 1, irqs_disabled(): 0, pid: 3216, name: xenstored
      2 locks held by xenstored/3216:
       #0:  (&u->bind_mutex){......}, at: [<ffffffffa02e0920>] evtchn_ioctl+0x30/0x3a0 [xen_evtchn]
       #1:  (irq_mapping_update_lock){......}, at: [<ffffffff8138b274>] bind_evtchn_to_irq+0x24/0x90
      Pid: 3216, comm: xenstored Not tainted 3.1.0-rc6-00021-g437a3d1 #2
      Call Trace:
       [<ffffffff81088d10>] __might_sleep+0x100/0x130
       [<ffffffff81645c2f>] mutex_lock_nested+0x2f/0x50
       [<ffffffff81627529>] __irq_alloc_descs+0x49/0x200
       [<ffffffffa02e0920>] ? evtchn_ioctl+0x30/0x3a0 [xen_evtchn]
       [<ffffffff8138b214>] xen_allocate_irq_dynamic+0x34/0x70
       [<ffffffff8138b2ad>] bind_evtchn_to_irq+0x5d/0x90
       [<ffffffffa02e03c0>] ? evtchn_bind_to_user+0x60/0x60 [xen_evtchn]
       [<ffffffff8138c282>] bind_evtchn_to_irqhandler+0x32/0x80
       [<ffffffffa02e03a9>] evtchn_bind_to_user+0x49/0x60 [xen_evtchn]
       [<ffffffffa02e0a34>] evtchn_ioctl+0x144/0x3a0 [xen_evtchn]
       [<ffffffff811b4070>] ? vfsmount_lock_local_unlock+0x50/0x80
       [<ffffffff811a6a1a>] do_vfs_ioctl+0x9a/0x5e0
       [<ffffffff811b476f>] ? mntput+0x1f/0x30
       [<ffffffff81196259>] ? fput+0x199/0x240
       [<ffffffff811a7001>] sys_ioctl+0xa1/0xb0
       [<ffffffff8164ea82>] system_call_fastpath+0x16/0x1b
      Reported-by: default avatarJim Burns <jim_burn@bellsouth.net>
      Acked-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      77365948
  2. 13 Sep, 2011 1 commit
    • David Vrabel's avatar
      xen/e820: if there is no dom0_mem=, don't tweak extra_pages. · e3b73c4a
      David Vrabel authored
      The patch "xen: use maximum reservation to limit amount of usable RAM"
      (d312ae87) breaks machines that
      do not use 'dom0_mem=' argument with:
      
      reserve RAM buffer: 000000133f2e2000 - 000000133fffffff
      (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff8117e
      (XEN) domain_crash_sync called from entry.S
      (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
      ...
      
      The reason being that the last E820 entry is created using the
      'extra_pages' (which is based on how many pages have been freed).
      The mentioned git commit sets the initial value of 'extra_pages'
      using a hypercall which returns the number of pages (if dom0_mem
      has been used) or -1 otherwise. If the later we return with
      MAX_DOMAIN_PAGES as basis for calculation:
      
          return min(max_pages, MAX_DOMAIN_PAGES);
      
      and use it:
      
           extra_limit = xen_get_max_pages();
           if (extra_limit >= max_pfn)
                   extra_pages = extra_limit - max_pfn;
           else
                   extra_pages = 0;
      
      which means we end up with extra_pages = 128GB in PFNs (33554432)
      - 8GB in PFNs (2097152, on this specific box, can be larger or smaller),
      and then we add that value to the E820 making it:
      
        Xen: 00000000ff000000 - 0000000100000000 (reserved)
        Xen: 0000000100000000 - 000000133f2e2000 (usable)
      
      which is clearly wrong. It should look as so:
      
        Xen: 00000000ff000000 - 0000000100000000 (reserved)
        Xen: 0000000100000000 - 000000027fbda000 (usable)
      
      Naturally this problem does not present itself if dom0_mem=max:X
      is used.
      
      CC: stable@kernel.org
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      e3b73c4a
  3. 08 Sep, 2011 1 commit
  4. 01 Sep, 2011 3 commits
  5. 22 Aug, 2011 2 commits
  6. 17 Aug, 2011 1 commit
    • Jan Beulich's avatar
      xen/x86: replace order-based range checking of M2P table by linear one · ccbcdf7c
      Jan Beulich authored
      The order-based approach is not only less efficient (requiring a shift
      and a compare, typical generated code looking like this
      
      	mov	eax, [machine_to_phys_order]
      	mov	ecx, eax
      	shr	ebx, cl
      	test	ebx, ebx
      	jnz	...
      
      whereas a direct check requires just a compare, like in
      
      	cmp	ebx, [machine_to_phys_nr]
      	jae	...
      
      ), but also slightly dangerous in the 32-on-64 case - the element
      address calculation can wrap if the next power of two boundary is
      sufficiently far away from the actual upper limit of the table, and
      hence can result in user space addresses being accessed (with it being
      unknown what may actually be mapped there).
      
      Additionally, the elimination of the mistaken use of fls() here (should
      have been __fls()) fixes a latent issue on x86-64 that would trigger
      if the code was run on a system with memory extending beyond the 44-bit
      boundary.
      
      CC: stable@kernel.org
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      [v1: Based on Jeremy's feedback]
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      ccbcdf7c
  7. 10 Aug, 2011 1 commit
    • Randy Dunlap's avatar
      xen: xen-selfballoon.c needs more header files · 30eefc95
      Randy Dunlap authored
      Fix build errors (found when CONFIG_SYSFS is not enabled):
      
      drivers/xen/xen-selfballoon.c:446: warning: data definition has no type or storage class
      drivers/xen/xen-selfballoon.c:446: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
      drivers/xen/xen-selfballoon.c:446: warning: parameter names (without types) in function declaration
      drivers/xen/xen-selfballoon.c:485: error: expected declaration specifiers or '...' before string constant
      drivers/xen/xen-selfballoon.c:485: warning: data definition has no type or storage class
      drivers/xen/xen-selfballoon.c:485: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
      drivers/xen/xen-selfballoon.c:485: warning: function declaration isn't a prototype
      Signed-off-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      30eefc95
  8. 05 Aug, 2011 1 commit
  9. 04 Aug, 2011 3 commits
  10. 03 Aug, 2011 4 commits
  11. 30 Jul, 2011 6 commits
  12. 28 Jul, 2011 15 commits