Skip to content
  1. Feb 01, 2018
    • Stanislav Lanci's avatar
      KVM: x86: AMD Processor Topology Information · 806793f5
      Stanislav Lanci authored
      
      
      This patch allow to enable x86 feature TOPOEXT. This is needed to provide
      information about SMT on AMD Zen CPUs to the guest.
      
      Signed-off-by: default avatarStanislav Lanci <pixo@polepetko.eu>
      Tested-by: default avatarNick Sarnie <commendsarnex@gmail.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarBabu Moger <babu.moger@amd.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      806793f5
    • Vitaly Kuznetsov's avatar
      x86/kvm/vmx: do not use vm-exit instruction length for fast MMIO when running nested · d391f120
      Vitaly Kuznetsov authored
      
      
      I was investigating an issue with seabios >= 1.10 which stopped working
      for nested KVM on Hyper-V. The problem appears to be in
      handle_ept_violation() function: when we do fast mmio we need to skip
      the instruction so we do kvm_skip_emulated_instruction(). This, however,
      depends on VM_EXIT_INSTRUCTION_LEN field being set correctly in VMCS.
      However, this is not the case.
      
      Intel's manual doesn't mandate VM_EXIT_INSTRUCTION_LEN to be set when
      EPT MISCONFIG occurs. While on real hardware it was observed to be set,
      some hypervisors follow the spec and don't set it; we end up advancing
      IP with some random value.
      
      I checked with Microsoft and they confirmed they don't fill
      VM_EXIT_INSTRUCTION_LEN on EPT MISCONFIG.
      
      Fix the issue by doing instruction skip through emulator when running
      nested.
      
      Fixes: 68c3b4d1
      Suggested-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Suggested-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      d391f120
    • Masatake YAMATO's avatar
      kvm: embed vcpu id to dentry of vcpu anon inode · e46b4692
      Masatake YAMATO authored
      
      
      All d-entries for vcpu have the same, "anon_inode:kvm-vcpu". That means
      it is impossible to know the mapping between fds for vcpu and vcpu
      from userland.
      
          # LC_ALL=C ls -l /proc/617/fd | grep vcpu
          lrwx------. 1 qemu qemu 64 Jan  7 16:50 18 -> anon_inode:kvm-vcpu
          lrwx------. 1 qemu qemu 64 Jan  7 16:50 19 -> anon_inode:kvm-vcpu
      
      It is also impossible to know the mapping between vma for kvm_run
      structure and vcpu from userland.
      
          # LC_ALL=C grep vcpu /proc/617/maps
          7f9d842d0000-7f9d842d3000 rw-s 00000000 00:0d 20393                      anon_inode:kvm-vcpu
          7f9d842d3000-7f9d842d6000 rw-s 00000000 00:0d 20393                      anon_inode:kvm-vcpu
      
      This change adds vcpu id to d-entries for vcpu. With this change
      you can get the following output:
      
          # LC_ALL=C ls -l /proc/617/fd | grep vcpu
          lrwx------. 1 qemu qemu 64 Jan  7 16:50 18 -> anon_inode:kvm-vcpu:0
          lrwx------. 1 qemu qemu 64 Jan  7 16:50 19 -> anon_inode:kvm-vcpu:1
      
          # LC_ALL=C grep vcpu /proc/617/maps
          7f9d842d0000-7f9d842d3000 rw-s 00000000 00:0d 20393                      anon_inode:kvm-vcpu:0
          7f9d842d3000-7f9d842d6000 rw-s 00000000 00:0d 20393                      anon_inode:kvm-vcpu:1
      
      With the mappings known from the output, a tool like strace can report more details
      of qemu-kvm process activities. Here is the strace output of my local prototype:
      
          # ./strace -KK -f -p 617 2>&1 | grep 'KVM_RUN\| K'
          ...
          [pid   664] ioctl(18, KVM_RUN, 0)       = 0 (KVM_EXIT_MMIO)
           K ready_for_interrupt_injection=1, if_flag=0, flags=0, cr8=0000000000000000, apic_base=0x000000fee00d00
           K phys_addr=0, len=1634035803, [33, 0, 0, 0, 0, 0, 0, 0], is_write=112
          [pid   664] ioctl(18, KVM_RUN, 0)       = 0 (KVM_EXIT_MMIO)
           K ready_for_interrupt_injection=1, if_flag=1, flags=0, cr8=0000000000000000, apic_base=0x000000fee00d00
           K phys_addr=0, len=1634035803, [33, 0, 0, 0, 0, 0, 0, 0], is_write=112
          ...
      
      Signed-off-by: default avatarMasatake YAMATO <yamato@redhat.com>
      Acked-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      e46b4692
    • KarimAllah Ahmed's avatar
      kvm: Map PFN-type memory regions as writable (if possible) · a340b3e2
      KarimAllah Ahmed authored
      
      
      For EPT-violations that are triggered by a read, the pages are also mapped with
      write permissions (if their memory region is also writable). That would avoid
      getting yet another fault on the same page when a write occurs.
      
      This optimization only happens when you have a "struct page" backing the memory
      region. So also enable it for memory regions that do not have a "struct page".
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: kvm@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarKarimAllah Ahmed <karahmed@amazon.de>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      a340b3e2
  2. Jan 31, 2018
  3. Jan 26, 2018
  4. Jan 25, 2018
  5. Jan 24, 2018
  6. Jan 23, 2018
  7. Jan 17, 2018
  8. Jan 16, 2018