1. 20 7月, 2008 4 次提交
    • A
      KVM: MMU: Avoid page prefetch on SVM · 131d8279
      Avi Kivity 提交于
      SVM cannot benefit from page prefetching since guest page fault bypass
      cannot by made to work there.  Avoid accessing the guest page table in
      this case.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      131d8279
    • A
      KVM: MMU: Move nonpaging_prefetch_page() · d761a501
      Avi Kivity 提交于
      In preparation for next patch. No code change.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      d761a501
    • A
      KVM: MMU: Fix false flooding when a pte points to page table · 1b7fcd32
      Avi Kivity 提交于
      The KVM MMU tries to detect when a speculative pte update is not actually
      used by demand fault, by checking the accessed bit of the shadow pte.  If
      the shadow pte has not been accessed, we deem that page table flooded and
      remove the shadow page table, allowing further pte updates to proceed
      without emulation.
      
      However, if the pte itself points at a page table and only used for write
      operations, the accessed bit will never be set since all access will happen
      through the emulator.
      
      This is exactly what happens with kscand on old (2.4.x) HIGHMEM kernels.
      The kernel points a kmap_atomic() pte at a page table, and then
      proceeds with read-modify-write operations to look at the dirty and accessed
      bits.  We get a false flood trigger on the kmap ptes, which results in the
      mmu spending all its time setting up and tearing down shadows.
      
      Fix by setting the shadow accessed bit on emulated accesses.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      1b7fcd32
    • H
      KVM: add statics were possible, function definition in lapic.h · 8b2cf73c
      Harvey Harrison 提交于
      Noticed by sparse:
      arch/x86/kvm/vmx.c:1583:6: warning: symbol 'vmx_disable_intercept_for_msr' was not declared. Should it be static?
      arch/x86/kvm/x86.c:3406:5: warning: symbol 'kvm_task_switch_16' was not declared. Should it be static?
      arch/x86/kvm/x86.c:3429:5: warning: symbol 'kvm_task_switch_32' was not declared. Should it be static?
      arch/x86/kvm/mmu.c:1968:6: warning: symbol 'kvm_mmu_remove_one_alloc_mmu_page' was not declared. Should it be static?
      arch/x86/kvm/mmu.c:2014:6: warning: symbol 'mmu_destroy_caches' was not declared. Should it be static?
      arch/x86/kvm/lapic.c:862:5: warning: symbol 'kvm_lapic_get_base' was not declared. Should it be static?
      arch/x86/kvm/i8254.c:94:5: warning: symbol 'pit_get_gate' was not declared. Should it be static?
      arch/x86/kvm/i8254.c:196:5: warning: symbol '__pit_timer_fn' was not declared. Should it be static?
      arch/x86/kvm/i8254.c:561:6: warning: symbol '__inject_pit_timer_intr' was not declared. Should it be static?
      Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      8b2cf73c
  2. 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
  3. 07 6月, 2008 2 次提交
  4. 23 5月, 2008 1 次提交
  5. 04 5月, 2008 6 次提交
  6. 27 4月, 2008 19 次提交
  7. 25 3月, 2008 3 次提交
  8. 04 3月, 2008 2 次提交
    • 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