Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1531972ybb; Thu, 26 Mar 2020 02:32:16 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsbOo9d0aQeV5r7tp9Rz/w1J8LmyH6HhUROgasrTRtYgrvxpI61V0AJr/izs5VpRg6KjnqU X-Received: by 2002:a9d:5c0c:: with SMTP id o12mr5526012otk.145.1585215136188; Thu, 26 Mar 2020 02:32:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585215136; cv=none; d=google.com; s=arc-20160816; b=bb0eE2rsuVZcALNLcbE1PITh3nBrzMn2pQa6jQeQhkU63OsiegKlyrlhsyNxUBtfdK h7+M0GuutWQZT2rtbvaJfudse2ykq61TtDRhvnR+KYRhhsCKJ2qKeQl2X4rrY/DXgcjr dXX1lnaH58Z4n91v+tzF1ihdarcaJxgxeBxcLOgcCXZR0gW0+uLn5R4/aacZ2PXZmva3 XuIhsOOQf4UDlIJOHZHFBQNQtXqHFu19U7u5wCiGQy7oKUAu7tQkybRjepppKDav0Oi/ 509QGTr4lExfPCKKZD7E1+bpAGgbkFqLciqfbGMonarf0CzXskDTfpC+YMNAgI/s+O3l iavA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=esTmH4cB/EmXs7bNIKOnrPOf53NVfIPgGSIfm/ZJE4I=; b=Wthi0obZt3+OjiQR7GWvPgul20VH1Tq0+LDBgOYYULjt19FkYb8DZ8lLGydxNYtaek NEppP+B3krnhmJMCZCH864xwX31WQ34r0ptYeP/fdICnAJZ0yu7qoUhYx1xM0D50KnwY jxsvTYNHB0v2kPJ2xQC7AcB4w0H5VgzfB+MxhdJC5bL0C9qyVVr1Px9Pw7EhZ7gNPGgc w9aH2iAtc7Wr1MGctrLBfIQIO3xj/XW5k0xdvKXgF0RTj/Q001aCuDarhddVqtdwFEcU Vm5nPNdothCsbWscnRsj3O3cNbXvEjT4/IIXQVJOZVlte5LgJreP5mAAOZfKacvim0pl 59Wg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x2si874629otj.19.2020.03.26.02.32.03; Thu, 26 Mar 2020 02:32:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727900AbgCZJaM (ORCPT + 99 others); Thu, 26 Mar 2020 05:30:12 -0400 Received: from mx2.suse.de ([195.135.220.15]:48286 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726354AbgCZJaM (ORCPT ); Thu, 26 Mar 2020 05:30:12 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B694EAF2C; Thu, 26 Mar 2020 09:30:10 +0000 (UTC) Subject: Re: [PATCH v3 2/2] x86/xen: Make the secondary CPU idle tasks reliable To: Miroslav Benes , boris.ostrovsky@oracle.com, sstabellini@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, jpoimboe@redhat.com Cc: x86@kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, jslaby@suse.cz, andrew.cooper3@citrix.com, jbeulich@suse.com References: <20200326092603.7230-1-mbenes@suse.cz> <20200326092603.7230-3-mbenes@suse.cz> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Thu, 26 Mar 2020 10:30:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200326092603.7230-3-mbenes@suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26.03.20 10:26, Miroslav Benes wrote: > The unwinder reports the secondary CPU idle tasks' stack on XEN PV as > unreliable, which affects at least live patching. > cpu_initialize_context() sets up the context of the CPU through > VCPUOP_initialise hypercall. After it is woken up, the idle task starts > in cpu_bringup_and_idle() function and its stack starts at the offset > right below pt_regs. The unwinder correctly detects the end of stack > there but it is confused by NULL return address in the last frame. > > Introduce a wrapper in assembly, which just calls > cpu_bringup_and_idle(). The return address is thus pushed on the stack > and the wrapper contains the annotation hint for the unwinder regarding > the stack state. > > Signed-off-by: Miroslav Benes Reviewed-by: Juergen Gross Juergen