From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D26CC43465 for ; Mon, 21 Sep 2020 13:46:10 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B94D32084C for ; Mon, 21 Sep 2020 13:46:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="yBRxQXtv"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="PBzsm4Ck" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B94D32084C Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.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=rxfh6av5W+GAeH9ZYnBK03wcGDE19UN5Iu+p4sB5g+o=; b=yBRxQXtvt5JeHeu+K6v0YMPk6 mqZE3zJW7PnTRmQ+tefiEqQf+mk0Vrduzlj8RjxS6wsjRRrYrZiDu7gXEmxdra/Dw9tMOIwNXfC3H JG1537LlxdLuzAlcbyclGY/8LPlsGfdWTinjS5IoPrnhMo+yvdB+IPLd4w2XrUotxCFfjoWl2fU5R 9ZZZQO6UEee+lBoewu6l+/4jlPb2dV18cwndGP8mr1R09JDCTB55KJ5/MMdo9udlsgrpdh3nWK2RT G0szVNag8po7bwvefVqOvB8nrbFETQh+Y4aGAtHSCGHXMl/9heUhi0HfhuOQf68x+1uW8xU9Tn98B 0P+oFoOCQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKM7d-00031M-NI; Mon, 21 Sep 2020 13:44:49 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKM6r-0002lr-0v for linux-arm-kernel@lists.infradead.org; Mon, 21 Sep 2020 13:44:02 +0000 Received: by mail-wr1-x444.google.com with SMTP id c18so12825053wrm.9 for ; Mon, 21 Sep 2020 06:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=PKSAlhSQ9Eh6fSSb1EiKiqDta1PeLzDdGDQlo2aRDw4=; b=PBzsm4CksVIWOwAwH9jC9VQ6MVHjGCDUXFV+y2ttxej8Xuexc6+aKCDyieHrP+XQ6r YXLZHVgtFM8leGT+Gsel61/uWf0Zz/wLwz3EmVcnWB/uk9xw8cvoNZaosyrBcTp6czSn /b4Kqxzo8vqQjA0Gd0WuUt4yNtDcFnoQJXKIHUnGTRPNaWBYlmiRZZkRM40+F6e2Kd1O Oxp/yRU5neltD3kropbYH+zuooXNi8ijWFjVPt38BkmsMGO6oVGBF6Y9lsgGrSZvGwyz 8KC52eHwemtmteuByjnIXT6hLwiRh0KKiS6+e8vHDDy7qRkjVf0IOiYsgsfzk2x+eQys xQdA== 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:in-reply-to; bh=PKSAlhSQ9Eh6fSSb1EiKiqDta1PeLzDdGDQlo2aRDw4=; b=FTeLYYD/zO82bAjuVfwPhcP3LlSX0kL2QsPLfxClNn8uLZ7sMNPeTMsd7gIKJOGEGJ OaPSmCS1tMg84lIgXhH5OVPAMXcVEmVhXbNbKroG2WVd9qcg7xb9B013qVP9ZHRSApC9 CoPE7SZbRV15L0c3MX6SE8x3HC86Mk6EoPswuAUi2Nzz/zE/Z9izvg2H+YjSD7cRJQwa KhhgKUjtSPBt4bjdQgnDEGmmsdMsHAtX3jwrxR96jjCpq5RdjEXS7kfEIdOhxlgrnBHk CUy2Deqxn+8Eue6vppU2fSx1FRaIcCxXbcrOf+81A7JeBozhTiGmVNYeJcwERA/AtyV6 En5w== X-Gm-Message-State: AOAM532i33zUy6y65NzX+mXicyuSC/dUvoOiaIKC1WWM+nQiC/w2l5RI zkfgcAT5zwCi64GfMFlRUrPxqQ== X-Google-Smtp-Source: ABdhPJz+M60dQM2XcDdmSU16x2fFPZSTR+TQAMTpZYcbvWrpRI6wunJ1bR4T+xWDSV5N+1CvR8M6oA== X-Received: by 2002:adf:cf01:: with SMTP id o1mr53523006wrj.421.1600695837833; Mon, 21 Sep 2020 06:43:57 -0700 (PDT) Received: from google.com ([2a01:4b00:8523:2d03:e5b6:fa6a:5f89:97d3]) by smtp.gmail.com with ESMTPSA id q4sm20497820wru.65.2020.09.21.06.43.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Sep 2020 06:43:57 -0700 (PDT) Date: Mon, 21 Sep 2020 14:43:55 +0100 From: David Brazdil To: Will Deacon Subject: Re: [PATCH v3 04/11] kvm: arm64: Remove __hyp_this_cpu_read Message-ID: <20200921134355.5lzma3qzyiexxepd@google.com> References: <20200916173439.32265-1-dbrazdil@google.com> <20200916173439.32265-5-dbrazdil@google.com> <20200918090029.GC30834@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200918090029.GC30834@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200921_094401_097734_AD5F4221 X-CRM114-Status: GOOD ( 19.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Suzuki K Poulose , Catalin Marinas , linux-kernel@vger.kernel.org, James Morse , linux-arm-kernel@lists.infradead.org, Marc Zyngier , Tejun Heo , Dennis Zhou , Christoph Lameter , kernel-team@android.com, kvmarm@lists.cs.columbia.edu, Julien Thierry , Andrew Scull Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Will, > > +static inline unsigned long __hyp_my_cpu_offset(void) > > +{ > > + unsigned long off; > > + > > + /* > > + * We want to allow caching the value, so avoid using volatile and > > + * instead use a fake stack read to hazard against barrier(). > > + */ > > I don't think we need to copy/paste the comment... > > > + asm("mrs %0, tpidr_el2" : "=r" (off) : > > + "Q" (*(const unsigned long *)current_stack_pointer)); > > ... especially given that we're not preemptible at EL2 with nVHE, maybe > we don't need to play this trick at all because we're always going to be > on the same CPU. So we could actually just do: > > return read_sysreg(tpidr_el2); > > which is much better, and the comment should say something to that effect. I must be misinterpreting the comment. I understood that it enables the compiler optimizing multiple reads of TPIDR by avoiding 'asm volatile' (signaling that the value does not change between reads). So what exactly does it do? read_sysreg expands to 'asm volatile' but I have no problem with priotizing readability over a micro-optimization. > > +#if defined(__KVM_NVHE_HYPERVISOR__) || defined(__KVM_VHE_HYPERVISOR__) > > +#define __my_cpu_offset __hyp_my_cpu_offset() > > Why would VHE code need to use this? Especially in light of my preemption > comments above, shouldn't it now be using __kern_my_cpu_offset()? During v2 review Andrew Scull pointed out we can avoid alternatives on VHE code by using __hyp_my_cpu_offset for it as well. Obviously if __hyp_my_cpu_offset becomes nVHE-specific, we can always move VHE back to __kern. This was just about saving a few cycles during boot. David _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel