1. 06 11月, 2013 1 次提交
  2. 05 11月, 2013 1 次提交
    • G
      KVM: IOMMU: hva align mapping page size · 27ef63c7
      Greg Edwards 提交于
      When determining the page size we could use to map with the IOMMU, the
      page size should also be aligned with the hva, not just the gfn.  The
      gfn may not reflect the real alignment within the hugetlbfs file.
      
      Most of the time, this works fine.  However, if the hugetlbfs file is
      backed by non-contiguous huge pages, a multi-huge page memslot starts at
      an unaligned offset within the hugetlbfs file, and the gfn is aligned
      with respect to the huge page size, kvm_host_page_size() will return the
      huge page size and we will use that to map with the IOMMU.
      
      When we later unpin that same memslot, the IOMMU returns the unmap size
      as the huge page size, and we happily unpin that many pfns in
      monotonically increasing order, not realizing we are spanning
      non-contiguous huge pages and partially unpin the wrong huge page.
      
      Ensure the IOMMU mapping page size is aligned with the hva corresponding
      to the gfn, which does reflect the alignment within the hugetlbfs file.
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NGreg Edwards <gedwards@ddn.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      27ef63c7
  3. 31 10月, 2013 3 次提交
  4. 30 10月, 2013 1 次提交
  5. 28 10月, 2013 1 次提交
    • Y
      KVM: Mapping IOMMU pages after updating memslot · e0230e13
      Yang Zhang 提交于
      In kvm_iommu_map_pages(), we need to know the page size via call
      kvm_host_page_size(). And it will check whether the target slot
      is valid before return the right page size.
      Currently, we will map the iommu pages when creating a new slot.
      But we call kvm_iommu_map_pages() during preparing the new slot.
      At that time, the new slot is not visible by domain(still in preparing).
      So we cannot get the right page size from kvm_host_page_size() and
      this will break the IOMMU super page logic.
      The solution is to map the iommu pages after we insert the new slot
      into domain.
      Signed-off-by: NYang Zhang <yang.z.zhang@Intel.com>
      Tested-by: NPatrick Lu <patrick.lu@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      e0230e13
  6. 17 10月, 2013 2 次提交
  7. 15 10月, 2013 1 次提交
  8. 03 10月, 2013 2 次提交
  9. 30 9月, 2013 3 次提交
    • P
      KVM: Convert kvm_lock back to non-raw spinlock · 2f303b74
      Paolo Bonzini 提交于
      In commit e935b837 ("KVM: Convert kvm_lock to raw_spinlock"),
      the kvm_lock was made a raw lock.  However, the kvm mmu_shrink()
      function tries to grab the (non-raw) mmu_lock within the scope of
      the raw locked kvm_lock being held.  This leads to the following:
      
      BUG: sleeping function called from invalid context at kernel/rtmutex.c:659
      in_atomic(): 1, irqs_disabled(): 0, pid: 55, name: kswapd0
      Preemption disabled at:[<ffffffffa0376eac>] mmu_shrink+0x5c/0x1b0 [kvm]
      
      Pid: 55, comm: kswapd0 Not tainted 3.4.34_preempt-rt
      Call Trace:
       [<ffffffff8106f2ad>] __might_sleep+0xfd/0x160
       [<ffffffff817d8d64>] rt_spin_lock+0x24/0x50
       [<ffffffffa0376f3c>] mmu_shrink+0xec/0x1b0 [kvm]
       [<ffffffff8111455d>] shrink_slab+0x17d/0x3a0
       [<ffffffff81151f00>] ? mem_cgroup_iter+0x130/0x260
       [<ffffffff8111824a>] balance_pgdat+0x54a/0x730
       [<ffffffff8111fe47>] ? set_pgdat_percpu_threshold+0xa7/0xd0
       [<ffffffff811185bf>] kswapd+0x18f/0x490
       [<ffffffff81070961>] ? get_parent_ip+0x11/0x50
       [<ffffffff81061970>] ? __init_waitqueue_head+0x50/0x50
       [<ffffffff81118430>] ? balance_pgdat+0x730/0x730
       [<ffffffff81060d2b>] kthread+0xdb/0xe0
       [<ffffffff8106e122>] ? finish_task_switch+0x52/0x100
       [<ffffffff817e1e94>] kernel_thread_helper+0x4/0x10
       [<ffffffff81060c50>] ? __init_kthread_worker+0x
      
      After the previous patch, kvm_lock need not be a raw spinlock anymore,
      so change it back.
      Reported-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: kvm@vger.kernel.org
      Cc: gleb@redhat.com
      Cc: jan.kiszka@siemens.com
      Reviewed-by: NGleb Natapov <gleb@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      2f303b74
    • P
      KVM: protect kvm_usage_count with its own spinlock · 4a937f96
      Paolo Bonzini 提交于
      The VM list need not be protected by a raw spinlock.  Separate the
      two so that kvm_lock can be made non-raw.
      
      Cc: kvm@vger.kernel.org
      Cc: gleb@redhat.com
      Cc: jan.kiszka@siemens.com
      Reviewed-by: NGleb Natapov <gleb@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4a937f96
    • P
      KVM: cleanup (physical) CPU hotplug · 4fa92fb2
      Paolo Bonzini 提交于
      Remove the useless argument, and do not do anything if there are no
      VMs running at the time of the hotplug.
      
      Cc: kvm@vger.kernel.org
      Cc: gleb@redhat.com
      Cc: jan.kiszka@siemens.com
      Reviewed-by: NGleb Natapov <gleb@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4fa92fb2
  10. 25 9月, 2013 1 次提交
  11. 17 9月, 2013 2 次提交
  12. 04 9月, 2013 1 次提交
  13. 30 8月, 2013 3 次提交
  14. 28 8月, 2013 1 次提交
  15. 27 8月, 2013 1 次提交
    • A
      kvm: optimize away THP checks in kvm_is_mmio_pfn() · 11feeb49
      Andrea Arcangeli 提交于
      The checks on PG_reserved in the page structure on head and tail pages
      aren't necessary because split_huge_page wouldn't transfer the
      PG_reserved bit from head to tail anyway.
      
      This was a forward-thinking check done in the case PageReserved was
      set by a driver-owned page mapped in userland with something like
      remap_pfn_range in a VM_PFNMAP region, but using hugepmds (not
      possible right now). It was meant to be very safe, but it's overkill
      as it's unlikely split_huge_page could ever run without the driver
      noticing and tearing down the hugepage itself.
      
      And if a driver in the future will really want to map a reserved
      hugepage in userland using an huge pmd it should simply take care of
      marking all subpages reserved too to keep KVM safe. This of course
      would require such a hypothetical driver to tear down the huge pmd
      itself and splitting the hugepage itself, instead of relaying on
      split_huge_page, but that sounds very reasonable, especially
      considering split_huge_page wouldn't currently transfer the reserved
      bit anyway.
      Signed-off-by: NAndrea Arcangeli <aarcange@redhat.com>
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      11feeb49
  16. 26 8月, 2013 1 次提交
  17. 29 7月, 2013 1 次提交
  18. 18 7月, 2013 2 次提交
  19. 27 6月, 2013 2 次提交
  20. 04 6月, 2013 1 次提交
    • A
      kvm: exclude ioeventfd from counting kvm_io_range limit · 6ea34c9b
      Amos Kong 提交于
      We can easily reach the 1000 limit by start VM with a couple
      hundred I/O devices (multifunction=on). The hardcode limit
      already been adjusted 3 times (6 ~ 200 ~ 300 ~ 1000).
      
      In userspace, we already have maximum file descriptor to
      limit ioeventfd count. But kvm_io_bus devices also are used
      for pit, pic, ioapic, coalesced_mmio. They couldn't be limited
      by maximum file descriptor.
      
      Currently only ioeventfds take too much kvm_io_bus devices,
      so just exclude it from counting kvm_io_range limit.
      
      Also fixed one indent issue in kvm_host.h
      Signed-off-by: NAmos Kong <akong@redhat.com>
      Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      6ea34c9b
  21. 19 5月, 2013 1 次提交
    • M
      ARM: KVM: move GIC/timer code to a common location · 7275acdf
      Marc Zyngier 提交于
      As KVM/arm64 is looming on the horizon, it makes sense to move some
      of the common code to a single location in order to reduce duplication.
      
      The code could live anywhere. Actually, most of KVM is already built
      with a bunch of ugly ../../.. hacks in the various Makefiles, so we're
      not exactly talking about style here. But maybe it is time to start
      moving into a less ugly direction.
      
      The include files must be in a "public" location, as they are accessed
      from non-KVM files (arch/arm/kernel/asm-offsets.c).
      
      For this purpose, introduce two new locations:
      - virt/kvm/arm/ : x86 and ia64 already share the ioapic code in
        virt/kvm, so this could be seen as a (very ugly) precedent.
      - include/kvm/  : there is already an include/xen, and while the
        intent is slightly different, this seems as good a location as
        any
      
      Eventually, we should probably have independant Makefiles at every
      levels (just like everywhere else in the kernel), but this is just
      the first step.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      7275acdf
  22. 14 5月, 2013 1 次提交
  23. 12 5月, 2013 1 次提交
  24. 09 5月, 2013 1 次提交
  25. 08 5月, 2013 1 次提交
    • A
      KVM: Fix kvm_irqfd_init initialization · 7dac16c3
      Asias He 提交于
      In commit a0f155e9 'KVM: Initialize irqfd from kvm_init()', when
      kvm_init() is called the second time (e.g kvm-amd.ko and kvm-intel.ko),
      kvm_arch_init() will fail with -EEXIST, then kvm_irqfd_exit() will be
      called on the error handling path. This way, the kvm_irqfd system will
      not be ready.
      
      This patch fix the following:
      
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff81c0721e>] _raw_spin_lock+0xe/0x30
      PGD 0
      Oops: 0002 [#1] SMP
      Modules linked in: vhost_net
      CPU 6
      Pid: 4257, comm: qemu-system-x86 Not tainted 3.9.0-rc3+ #757 Dell Inc. OptiPlex 790/0V5HMK
      RIP: 0010:[<ffffffff81c0721e>]  [<ffffffff81c0721e>] _raw_spin_lock+0xe/0x30
      RSP: 0018:ffff880221721cc8  EFLAGS: 00010046
      RAX: 0000000000000100 RBX: ffff88022dcc003f RCX: ffff880221734950
      RDX: ffff8802208f6ca8 RSI: 000000007fffffff RDI: 0000000000000000
      RBP: ffff880221721cc8 R08: 0000000000000002 R09: 0000000000000002
      R10: 00007f7fd01087e0 R11: 0000000000000246 R12: ffff8802208f6ca8
      R13: 0000000000000080 R14: ffff880223e2a900 R15: 0000000000000000
      FS:  00007f7fd38488e0(0000) GS:ffff88022dcc0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 000000022309f000 CR4: 00000000000427e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process qemu-system-x86 (pid: 4257, threadinfo ffff880221720000, task ffff880222bd5640)
      Stack:
       ffff880221721d08 ffffffff810ac5c5 ffff88022431dc00 0000000000000086
       0000000000000080 ffff880223e2a900 ffff8802208f6ca8 0000000000000000
       ffff880221721d48 ffffffff810ac8fe 0000000000000000 ffff880221734000
      Call Trace:
       [<ffffffff810ac5c5>] __queue_work+0x45/0x2d0
       [<ffffffff810ac8fe>] queue_work_on+0x8e/0xa0
       [<ffffffff810ac949>] queue_work+0x19/0x20
       [<ffffffff81009b6b>] irqfd_deactivate+0x4b/0x60
       [<ffffffff8100a69d>] kvm_irqfd+0x39d/0x580
       [<ffffffff81007a27>] kvm_vm_ioctl+0x207/0x5b0
       [<ffffffff810c9545>] ? update_curr+0xf5/0x180
       [<ffffffff811b66e8>] do_vfs_ioctl+0x98/0x550
       [<ffffffff810c1f5e>] ? finish_task_switch+0x4e/0xe0
       [<ffffffff81c054aa>] ? __schedule+0x2ea/0x710
       [<ffffffff811b6bf7>] sys_ioctl+0x57/0x90
       [<ffffffff8140ae9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
       [<ffffffff81c0f602>] system_call_fastpath+0x16/0x1b
      Code: c1 ea 08 38 c2 74 0f 66 0f 1f 44 00 00 f3 90 0f b6 03 38 c2 75 f7 48 83 c4 08 5b c9 c3 55 48 89 e5 66 66 66 66 90 b8 00 01 00 00 <f0> 66 0f c1 07 89 c2 66 c1 ea 08 38 c2 74 0c 0f 1f 00 f3 90 0f
      RIP  [<ffffffff81c0721e>] _raw_spin_lock+0xe/0x30
      RSP <ffff880221721cc8>
      CR2: 0000000000000000
      ---[ end trace 13fb1e4b6e5ab21f ]---
      Signed-off-by: NAsias He <asias@redhat.com>
      Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      7dac16c3
  26. 05 5月, 2013 1 次提交
  27. 02 5月, 2013 1 次提交
    • P
      KVM: PPC: Book3S: Add API for in-kernel XICS emulation · 5975a2e0
      Paul Mackerras 提交于
      This adds the API for userspace to instantiate an XICS device in a VM
      and connect VCPUs to it.  The API consists of a new device type for
      the KVM_CREATE_DEVICE ioctl, a new capability KVM_CAP_IRQ_XICS, which
      functions similarly to KVM_CAP_IRQ_MPIC, and the KVM_IRQ_LINE ioctl,
      which is used to assert and deassert interrupt inputs of the XICS.
      
      The XICS device has one attribute group, KVM_DEV_XICS_GRP_SOURCES.
      Each attribute within this group corresponds to the state of one
      interrupt source.  The attribute number is the same as the interrupt
      source number.
      
      This does not support irq routing or irqfd yet.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      5975a2e0
  28. 27 4月, 2013 2 次提交