qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Wolfgang Link <w.link@proxmox.com>
To: guangrong.xiao@linux.intel.com, pbonzini@redhat.com
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Problems with VM after kernel commit b18d5431acc7a2fd22767925f3a6f597aa4bd29e
Date: Fri, 13 Nov 2015 15:55:57 +0100	[thread overview]
Message-ID: <5645F9FD.2050807@proxmox.com> (raw)

Hi,

We have problems with a HP ProLiant DL380 Gen9 and Vm's with large 
amount of memory, grater then 30GB.

The problem is that the vm need about 10 sec to start to boot.
and when it comes to syncing the cpu clock, it takes a long time to 
finish this task.
What also occurs is the vcpus need at startup 100% cpu usage and take 
over 1 min.

I could pin down the problem to the following kernel patch
> commit b18d5431acc7a2fd22767925f3a6f597aa4bd29e
> Author: Xiao Guangrong <guangrong.xiao@linux.intel.com>
> Date:   Mon Jun 15 16:55:21 2015 +0800
>
>     KVM: x86: fix CR0.CD virtualization
>
>     Currently, CR0.CD is not checked when we virtualize memory cache 
> type for
>     noncoherent_dma guests, this patch fixes it by :
>
>     - setting UC for all memory if CR0.CD = 1
>     - zapping all the last sptes in MMU if CR0.CD is changed
>
>     Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
>     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 06a186b..2764381 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -8628,7 +8628,8 @@ static int get_ept_level(void)
>
>  static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool 
> is_mmio)
>  {
> -       u64 ret;
> +       u8 cache;
> +       u64 ipat = 0;
>
>         /* For VT-d and EPT combination
>          * 1. MMIO: always map as UC
> @@ -8641,16 +8642,27 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu 
> *vcpu, gfn_t gfn, bool is_mmio)
>          * 3. EPT without VT-d: always map as WB and set IPAT=1 to keep
>          *    consistent with host MTRR
>          */
> -       if (is_mmio)
> -               ret = MTRR_TYPE_UNCACHABLE << VMX_EPT_MT_EPTE_SHIFT;
> -       else if (kvm_arch_has_noncoherent_dma(vcpu->kvm))
> -               ret = kvm_get_guest_memory_type(vcpu, gfn) <<
> -                     VMX_EPT_MT_EPTE_SHIFT;
> -       else
> -               ret = (MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT)
> -                       | VMX_EPT_IPAT_BIT;
> +       if (is_mmio) {
> +               cache = MTRR_TYPE_UNCACHABLE;
> +               goto exit;
> +       }
>
> -       return ret;
> +       if (!kvm_arch_has_noncoherent_dma(vcpu->kvm)) {
> +               ipat = VMX_EPT_IPAT_BIT;
> +               cache = MTRR_TYPE_WRBACK;
> +               goto exit;
> +       }
> +
> +       if (kvm_read_cr0(vcpu) & X86_CR0_CD) {
> +               ipat = VMX_EPT_IPAT_BIT;
> +               cache = MTRR_TYPE_UNCACHABLE;
> +               goto exit;
> +       }
> +
> +       cache = kvm_get_guest_memory_type(vcpu, gfn);
> +
> +exit:
> +       return (cache << VMX_EPT_MT_EPTE_SHIFT) | ipat;
>  }
>
>  static int vmx_get_lpage_level(void)
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 43f0df7..43fdb10 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -621,6 +621,10 @@ int kvm_set_cr0(struct kvm_vcpu *vcpu, unsigned 
> long cr0)
>
>         if ((cr0 ^ old_cr0) & update_bits)
>                 kvm_mmu_reset_context(vcpu);
> +
> +       if ((cr0 ^ old_cr0) & X86_CR0_CD)
> +               kvm_zap_gfn_range(vcpu->kvm, 0, ~0ULL);
> +
>         return 0;
>  }
>  EXPORT_SYMBOL_GPL(kvm_set_cr0);

The problem is I do not understand exactly the patch and what it is doing!
How is this related to numa architecture and huge amount of Memory in Vm's?
Because when I test the same on a single socket machine there are no 
problems.

Thanks for any advice.

             reply	other threads:[~2015-11-13 15:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-13 14:55 Wolfgang Link [this message]
2015-11-13 15:01 ` [Qemu-devel] Problems with VM after kernel commit b18d5431acc7a2fd22767925f3a6f597aa4bd29e Paolo Bonzini
2015-11-13 15:03   ` Wolfgang Link
2015-11-13 15:04     ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5645F9FD.2050807@proxmox.com \
    --to=w.link@proxmox.com \
    --cc=guangrong.xiao@linux.intel.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).