All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] Problems with VM after kernel commit b18d5431acc7a2fd22767925f3a6f597aa4bd29e
@ 2015-11-13 14:55 Wolfgang Link
  2015-11-13 15:01 ` Paolo Bonzini
  0 siblings, 1 reply; 4+ messages in thread
From: Wolfgang Link @ 2015-11-13 14:55 UTC (permalink / raw)
  To: guangrong.xiao, pbonzini; +Cc: qemu-devel

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] Problems with VM after kernel commit b18d5431acc7a2fd22767925f3a6f597aa4bd29e
  2015-11-13 14:55 [Qemu-devel] Problems with VM after kernel commit b18d5431acc7a2fd22767925f3a6f597aa4bd29e Wolfgang Link
@ 2015-11-13 15:01 ` Paolo Bonzini
  2015-11-13 15:03   ` Wolfgang Link
  0 siblings, 1 reply; 4+ messages in thread
From: Paolo Bonzini @ 2015-11-13 15:01 UTC (permalink / raw)
  To: Wolfgang Link, guangrong.xiao; +Cc: qemu-devel



On 13/11/2015 15:55, Wolfgang Link wrote:
> 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.

This has been fixed already, and the fix is slowly propagating to the
stable kernels.

The fixes are:

- KVM: vmx: obey KVM_QUIRK_CD_NW_CLEARED (fixed already in 4.2)

- KVM: x86: obey KVM_X86_QUIRK_CD_NW_CLEARED in kvm_set_cr0() (in 4.4,
will be backported)

Paolo

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] Problems with VM after kernel commit b18d5431acc7a2fd22767925f3a6f597aa4bd29e
  2015-11-13 15:01 ` Paolo Bonzini
@ 2015-11-13 15:03   ` Wolfgang Link
  2015-11-13 15:04     ` Paolo Bonzini
  0 siblings, 1 reply; 4+ messages in thread
From: Wolfgang Link @ 2015-11-13 15:03 UTC (permalink / raw)
  To: Paolo Bonzini, guangrong.xiao; +Cc: qemu-devel

Thanks you for the quick reply and the good news.

Wolfgang
On 11/13/2015 04:01 PM, Paolo Bonzini wrote:
>
> On 13/11/2015 15:55, Wolfgang Link wrote:
>> 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.
> This has been fixed already, and the fix is slowly propagating to the
> stable kernels.
>
> The fixes are:
>
> - KVM: vmx: obey KVM_QUIRK_CD_NW_CLEARED (fixed already in 4.2)
>
> - KVM: x86: obey KVM_X86_QUIRK_CD_NW_CLEARED in kvm_set_cr0() (in 4.4,
> will be backported)
>
> Paolo
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] Problems with VM after kernel commit b18d5431acc7a2fd22767925f3a6f597aa4bd29e
  2015-11-13 15:03   ` Wolfgang Link
@ 2015-11-13 15:04     ` Paolo Bonzini
  0 siblings, 0 replies; 4+ messages in thread
From: Paolo Bonzini @ 2015-11-13 15:04 UTC (permalink / raw)
  To: Wolfgang Link, guangrong.xiao; +Cc: qemu-devel



On 13/11/2015 16:03, Wolfgang Link wrote:
> Thanks you for the quick reply and the good news.

BTW, for kernel issues please use kvm@vger.kernel.org :)

Paolo

> Wolfgang
> On 11/13/2015 04:01 PM, Paolo Bonzini wrote:
>>
>> On 13/11/2015 15:55, Wolfgang Link wrote:
>>> 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.
>> This has been fixed already, and the fix is slowly propagating to the
>> stable kernels.
>>
>> The fixes are:
>>
>> - KVM: vmx: obey KVM_QUIRK_CD_NW_CLEARED (fixed already in 4.2)
>>
>> - KVM: x86: obey KVM_X86_QUIRK_CD_NW_CLEARED in kvm_set_cr0() (in 4.4,
>> will be backported)
>>
>> Paolo
>>
> 
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-11-13 15:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-13 14:55 [Qemu-devel] Problems with VM after kernel commit b18d5431acc7a2fd22767925f3a6f597aa4bd29e Wolfgang Link
2015-11-13 15:01 ` Paolo Bonzini
2015-11-13 15:03   ` Wolfgang Link
2015-11-13 15:04     ` Paolo Bonzini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.