Re: [PATCH] powerpc/kvm/cma: Fix panic introduces by signed shift operation

2014-09-03 Thread Paolo Bonzini
Il 02/09/2014 18:13, Laurent Dufour ha scritto:
 fc95ca7284bc54953165cba76c3228bd2cdb9591 introduces a memset in
 kvmppc_alloc_hpt since the general CMA doesn't clear the memory it
 allocates.
 
 However, the size argument passed to memset is computed from a signed value
 and its signed bit is extended by the cast the compiler is doing. This lead
 to extremely large size value when dealing with order value = 31, and
 almost all the memory following the allocated space is cleaned. As a
 consequence, the system is panicing and may even fail spawning the kdump
 kernel.
 
 This fix makes use of an unsigned value for the memset's size argument to
 avoid sign extension. Among this fix, another shift operation which may
 lead to signed extended value too is also fixed.
 
 Cc: Alexey Kardashevskiy a...@ozlabs.ru
 Cc: Paul Mackerras pau...@samba.org
 Cc: Alexander Graf ag...@suse.de
 Cc: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
 Cc: Joonsoo Kim iamjoonsoo@lge.com
 Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
 Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com
 ---
  arch/powerpc/kvm/book3s_64_mmu_hv.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
 b/arch/powerpc/kvm/book3s_64_mmu_hv.c
 index 72c20bb16d26..79294c4c5015 100644
 --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
 +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
 @@ -62,10 +62,10 @@ long kvmppc_alloc_hpt(struct kvm *kvm, u32 *htab_orderp)
   }
  
   kvm-arch.hpt_cma_alloc = 0;
 - page = kvm_alloc_hpt(1  (order - PAGE_SHIFT));
 + page = kvm_alloc_hpt(1ul  (order - PAGE_SHIFT));
   if (page) {
   hpt = (unsigned long)pfn_to_kaddr(page_to_pfn(page));
 - memset((void *)hpt, 0, (1  order));
 + memset((void *)hpt, 0, (1ul  order));
   kvm-arch.hpt_cma_alloc = 1;
   }
  
 

Thanks, applied to kvm/master.

Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] KVM: PPC: e500mc: Add support for single threaded vcpus on e6500 core

2014-09-03 Thread Alexander Graf


On 01.09.14 11:01, Mihai Caraman wrote:
 ePAPR represents hardware threads as cpu node properties in device tree.
 So with existing QEMU, hardware threads are simply exposed as vcpus with
 one hardware thread.
 
 The e6500 core shares TLBs between hardware threads. Without tlb write
 conditional instruction, the Linux kernel uses per core mechanisms to
 protect against duplicate TLB entries.
 
 The guest is unable to detect real siblings threads, so it can't use the
 TLB protection mechanism. An alternative solution is to use the hypervisor
 to allocate different lpids to guest's vcpus that runs simultaneous on real
 siblings threads. On systems with two threads per core this patch halves
 the size of the lpid pool that the allocator sees and use two lpids per VM.
 Use even numbers to speedup vcpu lpid computation with consecutive lpids
 per VM: vm1 will use lpids 2 and 3, vm2 lpids 4 and 5, and so on.
 
 Signed-off-by: Mihai Caraman mihai.cara...@freescale.com

Thanks, applied both to kvm-ppc-queue.


Alex
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html