1. 24 6月, 2008 3 次提交
    • A
      KVM: MMU: Fix oops on guest userspace access to guest pagetable · 6bf6a953
      Avi Kivity 提交于
      KVM has a heuristic to unshadow guest pagetables when userspace accesses
      them, on the assumption that most guests do not allow userspace to access
      pagetables directly. Unfortunately, in addition to unshadowing the pagetables,
      it also oopses.
      
      This never triggers on ordinary guests since sane OSes will clear the
      pagetables before assigning them to userspace, which will trigger the flood
      heuristic, unshadowing the pagetables before the first userspace access. One
      particular guest, though (Xenner) will run the kernel in userspace, triggering
      the oops.  Since the heuristic is incorrect in this case, we can simply
      remove it.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      6bf6a953
    • M
      KVM: MMU: large page update_pte issue with non-PAE 32-bit guests (resend) · 30945387
      Marcelo Tosatti 提交于
      kvm_mmu_pte_write() does not handle 32-bit non-PAE large page backed
      guests properly. It will instantiate two 2MB sptes pointing to the same
      physical 2MB page when a guest large pte update is trapped.
      
      Instead of duplicating code to handle this, disallow directory level
      updates to happen through kvm_mmu_pte_write(), so the two 2MB sptes
      emulating one guest 4MB pte can be correctly created by the page fault
      handling path.
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      30945387
    • M
      KVM: MMU: Fix rmap_write_protect() hugepage iteration bug · 6597ca09
      Marcelo Tosatti 提交于
      rmap_next() does not work correctly after rmap_remove(), as it expects
      the rmap chains not to change during iteration.  Fix (for now) by restarting
      iteration from the beginning.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      6597ca09
  2. 07 6月, 2008 2 次提交
  3. 23 5月, 2008 1 次提交
  4. 04 5月, 2008 6 次提交
  5. 27 4月, 2008 19 次提交
  6. 25 3月, 2008 3 次提交
  7. 04 3月, 2008 3 次提交
    • A
      KVM: MMU: Fix race when instantiating a shadow pte · f7d9c7b7
      Avi Kivity 提交于
      For improved concurrency, the guest walk is performed concurrently with other
      vcpus.  This means that we need to revalidate the guest ptes once we have
      write-protected the guest page tables, at which point they can no longer be
      modified.
      
      The current code attempts to avoid this check if the shadow page table is not
      new, on the assumption that if it has existed before, the guest could not have
      modified the pte without the shadow lock.  However the assumption is incorrect,
      as the racing vcpu could have modified the pte, then instantiated the shadow
      page, before our vcpu regains control:
      
        vcpu0        vcpu1
      
        fault
        walk pte
      
                     modify pte
                     fault in same pagetable
                     instantiate shadow page
      
        lookup shadow page
        conclude it is old
        instantiate spte based on stale guest pte
      
      We could do something clever with generation counters, but a test run by
      Marcelo suggests this is unnecessary and we can just do the revalidation
      unconditionally.  The pte will be in the processor cache and the check can
      be quite fast.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      f7d9c7b7
    • M
      KVM: make MMU_DEBUG compile again · 24993d53
      Marcelo Tosatti 提交于
      the cr3 variable is now inside the vcpu->arch structure.
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      24993d53
    • I
      KVM: remove the usage of the mmap_sem for the protection of the memory slots. · 72dc67a6
      Izik Eidus 提交于
      This patch replaces the mmap_sem lock for the memory slots with a new
      kvm private lock, it is needed beacuse untill now there were cases where
      kvm accesses user memory while holding the mmap semaphore.
      Signed-off-by: NIzik Eidus <izike@qumranet.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      72dc67a6
  8. 31 1月, 2008 3 次提交