From patchwork Thu Aug 22 13:20:00 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Aneesh Kumar K.V" X-Patchwork-Id: 2848256 Return-Path: X-Original-To: patchwork-kvm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id A8CFA9F271 for ; Thu, 22 Aug 2013 13:20:29 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id C558F20456 for ; Thu, 22 Aug 2013 13:20:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DC15720453 for ; Thu, 22 Aug 2013 13:20:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752563Ab3HVNUK (ORCPT ); Thu, 22 Aug 2013 09:20:10 -0400 Received: from e28smtp02.in.ibm.com ([122.248.162.2]:53050 "EHLO e28smtp02.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752466Ab3HVNUI (ORCPT ); Thu, 22 Aug 2013 09:20:08 -0400 Received: from /spool/local by e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 22 Aug 2013 18:39:55 +0530 Received: from d28dlp03.in.ibm.com (9.184.220.128) by e28smtp02.in.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 22 Aug 2013 18:39:52 +0530 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by d28dlp03.in.ibm.com (Postfix) with ESMTP id 274781258056; Thu, 22 Aug 2013 18:49:49 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r7MDLWag35848446; Thu, 22 Aug 2013 18:51:32 +0530 Received: from d28av03.in.ibm.com (localhost [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r7MDK0gB003279; Thu, 22 Aug 2013 18:50:01 +0530 Received: from skywalker.linux.vnet.ibm.com ([9.79.217.96]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r7MDK01h003276; Thu, 22 Aug 2013 18:50:00 +0530 From: "Aneesh Kumar K.V" To: Alexander Graf Cc: Paul Mackerras , "kvm-ppc\@vger.kernel.org" , "kvm\@vger.kernel.org list" Subject: Re: [PATCH] target-ppc: Update slb array with correct index values. In-Reply-To: <14BF15D9-CF86-43F8-9327-7B2BB42FFEFF@suse.de> References: <1376245011-20008-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <8810AF54-BB64-4313-AD32-C42608527B38@suse.de> <874nam5ei5.fsf@linux.vnet.ibm.com> <20130821051112.GB14481@iris.ozlabs.ibm.com> <4A3B1A8D-C1DC-41A7-A7ED-95C9FC791BA1@suse.de> <20130821092556.GC14481@iris.ozlabs.ibm.com> <3D410934-51C0-43D3-BC5B-BC3B40D2C8B8@suse.de> <87vc2zkpb0.fsf@linux.vnet.ibm.com> <14BF15D9-CF86-43F8-9327-7B2BB42FFEFF@suse.de> User-Agent: Notmuch/0.15.2+167~g5306b2b (http://notmuchmail.org) Emacs/24.3.50.1 (x86_64-unknown-linux-gnu) Date: Thu, 22 Aug 2013 18:50:00 +0530 Message-ID: <87k3jd277j.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13082213-5816-0000-0000-000009892432 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Status: No, score=-9.7 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Alexander Graf writes: > Am 21.08.2013 um 16:59 schrieb "Aneesh Kumar K.V" : > >> Alexander Graf writes: >> >> >> .... >> >>>> >>>> On HV KVM yes, that would be the end of the list, but PR KVM could >>>> give you entry 0 containing esid==0 and vsid==0 followed by valid >>>> entries. Perhaps the best approach is to ignore any entries with >>>> SLB_ESID_V clear. >>> >>> That means we don't clear entries we don't receive from the kernel because they're V=0 but which were V=1 before. Which with the current code is probably already broken. >>> >>> So yes, clear all cached entries first (to make sure we have no stale >>> ones), then loop through all and only add entries with V=1 should fix >>> everything for PR as well as HV. >> >> This is more or less what the patch is doing. The kernel already >> does memset of all the slb entries. The only difference is we don't >> depend on the slb index in the return value. Instead we just use the >> array index as the slb index. Do we really need to make sure the slb >> index remain same ? > > Yes, otherwise get/set change SLB numbering which the guest doesn't > expect. how about --- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c index 30a870e..313f866 100644 --- a/target-ppc/kvm.c +++ b/target-ppc/kvm.c @@ -1033,9 +1033,21 @@ int kvm_arch_get_registers(CPUState *cs) /* Sync SLB */ #ifdef TARGET_PPC64 + /* + * KVM_GET_SREGS doesn't retun slb entry with slot information + * same as index. So don't depend on the slot information in + * the returned value. + * Zero out the SLB array invalidating all the entries + */ + memset(env->slb, 0, 64 * sizeof(ppc_slb_t)); for (i = 0; i < 64; i++) { - ppc_store_slb(env, sregs.u.s.ppc64.slb[i].slbe, - sregs.u.s.ppc64.slb[i].slbv); + target_ulong rb = sregs.u.s.ppc64.slb[i].slbe; + target_ulong rs = sregs.u.s.ppc64.slb[i].slbv; + /* + * Only restore valid entries + */ + if (rb & SLB_ESID_V) + ppc_store_slb(env, rb, rs); } #endif