1. 24 1月, 2013 1 次提交
  2. 22 1月, 2013 3 次提交
  3. 14 1月, 2013 7 次提交
  4. 11 1月, 2013 2 次提交
    • X
      KVM: MMU: fix infinite fault access retry · 7751babd
      Xiao Guangrong 提交于
      We have two issues in current code:
      - if target gfn is used as its page table, guest will refault then kvm will use
        small page size to map it. We need two #PF to fix its shadow page table
      
      - sometimes, say a exception is triggered during vm-exit caused by #PF
        (see handle_exception() in vmx.c), we remove all the shadow pages shadowed
        by the target gfn before go into page fault path, it will cause infinite
        loop:
        delete shadow pages shadowed by the gfn -> try to use large page size to map
        the gfn -> retry the access ->...
      
      To fix these, we can adjust page size early if the target gfn is used as page
      table
      Signed-off-by: NXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      7751babd
    • X
      KVM: MMU: fix Dirty bit missed if CR0.WP = 0 · c2288505
      Xiao Guangrong 提交于
      If the write-fault access is from supervisor and CR0.WP is not set on the
      vcpu, kvm will fix it by adjusting pte access - it sets the W bit on pte
      and clears U bit. This is the chance that kvm can change pte access from
      readonly to writable
      
      Unfortunately, the pte access is the access of 'direct' shadow page table,
      means direct sp.role.access = pte_access, then we will create a writable
      spte entry on the readonly shadow page table. It will cause Dirty bit is
      not tracked when two guest ptes point to the same large page. Note, it
      does not have other impact except Dirty bit since cr0.wp is encoded into
      sp.role
      
      It can be fixed by adjusting pte access before establishing shadow page
      table. Also, after that, no mmu specified code exists in the common function
      and drop two parameters in set_spte
      Signed-off-by: NXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      c2288505
  5. 10 1月, 2013 7 次提交
  6. 09 1月, 2013 2 次提交
  7. 08 1月, 2013 2 次提交
  8. 03 1月, 2013 7 次提交
  9. 23 12月, 2012 7 次提交
  10. 18 12月, 2012 1 次提交
    • N
      kvm: fix i8254 counter 0 wraparound · d4b06c2d
      Nickolai Zeldovich 提交于
      The kvm i8254 emulation for counter 0 (but not for counters 1 and 2)
      has at least two bugs in mode 0:
      
      1. The OUT bit, computed by pit_get_out(), is never set high.
      
      2. The counter value, computed by pit_get_count(), wraps back around to
         the initial counter value, rather than wrapping back to 0xFFFF
         (which is the behavior described in the comment in __kpit_elapsed,
         the behavior implemented by qemu, and the behavior observed on AMD
         hardware).
      
      The bug stems from __kpit_elapsed computing the elapsed time mod the
      initial counter value (stored as nanoseconds in ps->period).  This is both
      unnecessary (none of the callers of kpit_elapsed expect the value to be
      at most the initial counter value) and incorrect (it causes pit_get_count
      to appear to wrap around to the initial counter value rather than 0xFFFF).
      Removing this mod from __kpit_elapsed fixes both of the above bugs.
      Signed-off-by: NNickolai Zeldovich <nickolai@csail.mit.edu>
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      d4b06c2d
  11. 15 12月, 2012 1 次提交