Received: by 10.213.65.68 with SMTP id h4csp906884imn; Sun, 25 Mar 2018 17:41:05 -0700 (PDT) X-Google-Smtp-Source: AG47ELtToboLgEi9W0fqZ2fTZ1us4/ltOOc+AwyJnIUFKftFyP5ZBP1UYejbsZ7mcU5gh2BXmiDv X-Received: by 2002:a17:902:8483:: with SMTP id c3-v6mr35372950plo.156.1522024865003; Sun, 25 Mar 2018 17:41:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522024864; cv=none; d=google.com; s=arc-20160816; b=Rd3FB465QdSyIjCoJOS54rAPinb3+rn2KPNCIe0rgqHiIGcBnyD73QL2ijy+duJyOK eY0wHHllwEdrY9BQ04fmdUgLFmthlORSYiNuwo2QtxqFshC78Ck9Yo1kfOI6bTtnESSy BCjAh9oxNoc+IxdDLgS+qt6IV10O1//qGQBWoDpIHFKFNuSDOHs4k1HKPZ2siRE6kAiY YnUQLq8WtcsCL4lbjMlU37ymRvNT/n/ZJ8Vik+Myur0VCD/tF7KD9m0WtoV1zcJABxA2 Y8W+UUa2AwobN9NanVbFJtJ4I+/nEsnO7zyd2uzb4dUbd0ryYkMfpn+3g7CdVMjijYEL rp/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=lRGLj5jo01TZwTJJFjHUFl90D/oUR/6nsSe9JstOEos=; b=XJgl1VbHYZWRIpuawP9UpN6kvYhQSh0sKCpPNRbYV+P2PpsUTUQqMqPVbqnTHZhFAS wHgRCRwiZqO/BGLnCBgJtNr8yxYsKi4WtWwyKvGkHC13hg/DapEs0jNq71+civIKStXP +2gH3PXLYhheJK0gqeX4gV8y0b5u2c5bxWzKyKsaUpLK3SF3gr4h0ebGfqcHZotWpY8M //aZukTRUWs7/ZTuS0dyooOSnsU9hqzL+q7h8MFyeCeeGpvh9b/NCqm0WGF3jJ99mzui JpA45BWcSsMoibZ6KDAoVuAWPuBtVvQKiHQc/KYl+lUiomdXmwBJVVsDqsw+i8JL9lM/ zgdA== 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 b5-v6si12064292pli.442.2018.03.25.17.40.50; Sun, 25 Mar 2018 17:41:04 -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 S1751714AbeCZAjx (ORCPT + 99 others); Sun, 25 Mar 2018 20:39:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:39633 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750832AbeCZAju (ORCPT ); Sun, 25 Mar 2018 20:39:50 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B698FACC0; Mon, 26 Mar 2018 00:39:48 +0000 (UTC) Date: Sun, 25 Mar 2018 17:27:32 -0700 From: Davidlohr Bueso To: Wanpeng Li , peterz@infradead.org Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Paolo Bonzini , Radim Kr??m??? , Davidlohr Bueso Subject: Re: [PATCH 1/2] KVM: X86: Fix setup the virt_spin_lock_key before static key get initialized Message-ID: <20180326002732.qks4cp7qq2xzysnx@linux-n805> References: <1521951444-5087-1-git-send-email-wanpengli@tencent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <1521951444-5087-1-git-send-email-wanpengli@tencent.com> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 24 Mar 2018, Wanpeng Li wrote: >Note: Peterz pointed out in the IRC we have to audit all the architectures that >implement smp_prepare_boot_cpu() to see what they depend on if we want to move >jump_label_init() before smp_prepare_boot_cpu(). So what this patch does is >similar to the issue which handled in xen ca5d376e. After some auditing, the jump_label_init() being moved before smp_prepare_boot_cpu() seems fine, however, bulky mechanisms to update text segments conflict with early smp bootup stages, such as this patch. So, while the disabling virt_spin_lock_key would be done correctly _after_ jump_label_init(), it is still fragile in that we want to be using lightweight patching such as jump_label_transform_static() -- which doesn't take the text_mutex (blocking is out of the question), for example. For pretty much all archs this means using the transform_static() version. For example x86, this means using text_poke_early(). -- also ouchy on the !PageReserved(pages[0]) warning for text_poke(). I'm not sure yet of the best way to teach jump_label_transform() to behave like jump_label_transform_static() under pre-smp bootup, such as when disabling hypervisor pvspinlocks. The s390 implementation seems safe as is given that stop_machine is now safe for early pre-smp boot. Thanks, Davidlohr