Re: [Qemu-devel] [PATCH 1/3] kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()

2017-09-15 Thread Greg Kurz
On Fri, 15 Sep 2017 07:32:10 +0200 Thomas Huth wrote: > On 14.09.2017 21:25, Greg Kurz wrote: > > On a server-class ppc host, this capability depends on the KVM type, > > ie, HV or PR. If both KVM are present in the kernel, we will always > > get the HV specific value, even if

Re: [Qemu-devel] [PATCH 1/3] kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()

2017-09-14 Thread Thomas Huth
On 14.09.2017 21:25, Greg Kurz wrote: > On a server-class ppc host, this capability depends on the KVM type, > ie, HV or PR. If both KVM are present in the kernel, we will always > get the HV specific value, even if we explicitely requested PR on > the command line. > > This can have an impact if

Re: [Qemu-devel] [PATCH 1/3] kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()

2017-09-14 Thread David Gibson
On Thu, Sep 14, 2017 at 09:25:22PM +0200, Greg Kurz wrote: > On a server-class ppc host, this capability depends on the KVM type, > ie, HV or PR. If both KVM are present in the kernel, we will always > get the HV specific value, even if we explicitely requested PR on > the command line. > > This

[Qemu-devel] [PATCH 1/3] kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()

2017-09-14 Thread Greg Kurz
On a server-class ppc host, this capability depends on the KVM type, ie, HV or PR. If both KVM are present in the kernel, we will always get the HV specific value, even if we explicitely requested PR on the command line. This can have an impact if we're using hugepages or a balloon device. Since