From patchwork Thu Dec 14 13:09:54 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Christoffer Dall X-Patchwork-Id: 10111997 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7E16E60327 for ; Thu, 14 Dec 2017 13:11:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6C79D29BE4 for ; Thu, 14 Dec 2017 13:11:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6122F29C3A; Thu, 14 Dec 2017 13:11:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id B8FC229BE4 for ; Thu, 14 Dec 2017 13:11:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XyTcxFwbWB1DsjRvi3gz1kOSj4LkeyQG69usUf9KFbY=; b=PPHKVWcDSRCouX iF/Do9i1TqN9OBmJjKfHTC2HIV7XLYbVJ4+R0P+siV1uKl+wHFv3z8TeEnBardOd6sHb3C6p1fRMr YXjUlP9W1WNdhpJ03XdgnBPOsle7fN/Ak0OcFIIGpYt3+6tvcdBSDP5KK+ty1FgEfSeVJ2XhZ/zCq TGiuv7UVANPW57B5Welx9dXbBW3hr/RiyzhX+UljLT/J0H4f3AoTwUdk5T8nJQo0n85hWrzCNsCdo /rhjmZeYzEUVMaaoRHnIIT8XmTxTOWm4d7t/d+DEgK7mbQ3lrsY9IWGKEWAuxZg3cIBd3mxSYoExl T+y9xasYhB1Axv9ZFyAw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1ePTHk-0008TW-32; Thu, 14 Dec 2017 13:10:48 +0000 Received: from mail-wm0-x243.google.com ([2a00:1450:400c:c09::243]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1ePTHd-0006hK-C2 for linux-arm-kernel@lists.infradead.org; Thu, 14 Dec 2017 13:10:46 +0000 Received: by mail-wm0-x243.google.com with SMTP id f206so11262166wmf.5 for ; Thu, 14 Dec 2017 05:10:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=r8n8M+O2PD8EQxSNVbdf+UjZ4pdYtMGD6J7tKyX/LiU=; b=RXgtjQ8MUlKNQI/MsWeumRpyHwVAzVWrm2POHdvR8kz4I1xyH8G93eOFKIp3NDV+PM oERFOOl1SpTMfiJ4p0+/Bp2avf8WYDURWMu81ViYpB1QhifZJe8c0b8jhhs5LDoukqEy p0nvwkM+h7sl8iQJ74BVLydq5+la6Gt4973d8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=r8n8M+O2PD8EQxSNVbdf+UjZ4pdYtMGD6J7tKyX/LiU=; b=GI0uRCianlN3UVqRa2kVody9AqZ1Cj4ikxDK2FoHssCTLrBkY79BjOziCSX+8yIKno HmxGWMzEuKm4pw77wB1Ca+BIuALOklrpZEPqHfS/dO6EOdieAC0pZEmuY8AyC9pqUwFY R/WYIuY33/celN1nyIQ5rRN5r8tfC4r0f1/pQyzxOYbyIgPPezCHEqx62cJHtTrzpbrs ErM1SI3wUqGRfuYYmCReZYWurCqpj9OqW9hXIB2bwN5GvhsgiVcXUVYB2Kl7E2Hol3V+ 3g4feustswaFNm60OGFmi8eWPhjFvR88Q+S6jz67zKDGqaDZwyjM4N8Xv+7y40aklE2+ qPUQ== X-Gm-Message-State: AKGB3mLzSU2SUbdFr/p2xV8c45JGASxOGxDCabnPUdWjvzc8SMr/z1nK oUptOfikG3L8nEQpvwPmi4JurKjf5EA= X-Google-Smtp-Source: ACJfBotLGOWOzPPTidLgjbyfgHKgcvP4h79ZDIP7oAeJ4t39IFN6ain2tCJ60Ny4qO7VzPXVmRhOlg== X-Received: by 10.80.130.36 with SMTP id 33mr12760396edf.252.1513257001138; Thu, 14 Dec 2017 05:10:01 -0800 (PST) Received: from localhost (x50d2404e.cust.hiper.dk. [80.210.64.78]) by smtp.gmail.com with ESMTPSA id b7sm3344227eda.60.2017.12.14.05.09.59 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 14 Dec 2017 05:09:59 -0800 (PST) Date: Thu, 14 Dec 2017 14:09:54 +0100 From: Christoffer Dall To: Jia He Subject: Re: [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler Message-ID: <20171214130954.GV910@cbox> References: <1513148407-2611-1-git-send-email-hejianet@gmail.com> <20171213091803.GQ910@cbox> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20171214_051041_600310_6C72E363 X-CRM114-Status: GOOD ( 20.08 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , Jia He , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, Dec 14, 2017 at 12:57:54PM +0800, Jia He wrote: Hi Jia, > > I have tried your newer level-mapped-v7 branch, but bug is still there. > > There is no special load in both host and guest. The guest (kernel > 4.14) is often hanging when booting > > the guest kernel log > > [ OK ] Reached target Remote File Systems. > Starting File System Check on /dev/mapper/fedora-root... > [ OK ] Started File System Check on /dev/mapper/fedora-root. > Mounting /sysroot... > [ 2.670764] SGI XFS with ACLs, security attributes, no debug enabled > [ 2.678180] XFS (dm-0): Mounting V5 Filesystem > [ 2.740364] XFS (dm-0): Ending clean mount > [ OK ] Mounted /sysroot. > [ OK ] Reached target Initrd Root File System. > Starting Reload Configuration from the Real Root... > [ 61.288215] INFO: rcu_sched detected stalls on CPUs/tasks: > [ 61.290791] 1-...!: (0 ticks this GP) idle=574/0/0 softirq=5/5 fqs=1 > [ 61.293664] (detected by 0, t=6002 jiffies, g=-263, c=-264, q=39760) > [ 61.296480] Task dump for CPU 1: > [ 61.297938] swapper/1 R running task 0 0 1 0x00000020 > [ 61.300643] Call trace: > [ 61.301260] __switch_to+0x6c/0x78 > [ 61.302095] cpu_number+0x0/0x8 > [ 61.302867] rcu_sched kthread starved for 6000 jiffies! > g18446744073709551353 c18446744073709551352 f0x0 RCU_GP_WAIT_FQS(3) > ->state=0x402 ->cpu=1 > [ 61.305941] rcu_sched I 0 8 2 0x00000020 > [ 61.307250] Call trace: > [ 61.307854] __switch_to+0x6c/0x78 > [ 61.308693] __schedule+0x268/0x8f0 > [ 61.309545] schedule+0x2c/0x88 > [ 61.310325] schedule_timeout+0x84/0x3b8 > [ 61.311278] rcu_gp_kthread+0x4d4/0x7d8 > [ 61.312213] kthread+0x134/0x138 > [ 61.313001] ret_from_fork+0x10/0x1c > > Maybe my previous patch is not perfect enough, thanks for your comments. > > I digged it futher more, do you think below code logic is possibly > problematic? > > > vtimer_save_state           (vtimer->loaded = false, cntv_ctl is 0) > > kvm_arch_timer_handler        (read cntv_ctl and set vtimer->cnt_ctl = 0) > > vtimer_restore_state            (write vtimer->cnt_ctl to cntv_ctl, > then cntv_ctl will > >                        be 0 forever) > > > If above analysis is reasonable Yes, I think there's something there if the hardware doesn't retire the signal fast enough... > how about below patch? already > tested in my arm64 server. > > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c > index f9555b1..ee6dd3f 100644 > --- a/virt/kvm/arm/arch_timer.c > +++ b/virt/kvm/arm/arch_timer.c > @@ -99,7 +99,7 @@ static irqreturn_t kvm_arch_timer_handler(int irq, > void *dev_id) >         } >         vtimer = vcpu_vtimer(vcpu); > > -       if (!vtimer->irq.level) { > +       if (vtimer->loaded && !vtimer->irq.level) { >                 vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl); >                 if (kvm_timer_irq_can_fire(vtimer)) >                         kvm_timer_update_irq(vcpu, true, vtimer); > There's nothing really wrong with that patch, I just didn't think it would be necessary, as we really shouldn't see interrupts if the timer is not loaded. Can you confirm that a WARN_ON(!vtimer->loaded) in kvm_arch_timer_handler() gives you a splat? Also, could you give the following a try (without your patch): Thanks, -Christoffer diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c index 73d262c4712b..4751255345d1 100644 --- a/virt/kvm/arm/arch_timer.c +++ b/virt/kvm/arm/arch_timer.c @@ -367,6 +367,7 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu) /* Disable the virtual timer */ write_sysreg_el0(0, cntv_ctl); + isb(); vtimer->loaded = false; out: