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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3553C433EF for ; Mon, 16 May 2022 15:14:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244819AbiEPPOq (ORCPT ); Mon, 16 May 2022 11:14:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230372AbiEPPOo (ORCPT ); Mon, 16 May 2022 11:14:44 -0400 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 624E93BA6B for ; Mon, 16 May 2022 08:14:43 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id q7so3311376plx.3 for ; Mon, 16 May 2022 08:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=18f9yUH1/w73tmifgqC4XWy7DHTtV6nZ9pn9JLOs8G4=; b=BMoeDTwmiLVu4Yp7Hb0ZS2ktRN19j8if9lN2p7YpJuwfvZMETAPUAdeU+YJo8AMPlg MCmCHbU/CKD+LiJ4Pjfxlbhvfk/1AnBjSBNX8oqKjnw2ya2zf2vVny5Md7+vJt+qJmrb BUOkJ4YyEHH5sBZGFEGxEMDm4W4V9BG0n98a8oqKwLXaVlrIeEkMuA2dKL21KgzGM9Az 4SxA5msjI+ifRYKYSZrH/gue3IMkfqclFB9pBj2pz1khU112i/89GzVXLgdUDbOb4R1b 46QRgkkcE/HkoH2njsKRysihh3Y2ZFmA78C3nh8fkKStwO/MW/69ph4fWii92pqlgvno b92A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=18f9yUH1/w73tmifgqC4XWy7DHTtV6nZ9pn9JLOs8G4=; b=QID+IFmOGzGGeIHUmRwSHvhJGzvCV7nUbma8BQatpk4NBaC77CJmJKOWgy4uq0Qfj5 U36b1xoIm6XRm1aeGWoDQHxW+rRByQaWVUujVtYZvdqX7dlrrKBM9mUhs9j/yKQQibXj CLKwHjVZxfsW3ofhBdL5dvqQevbShea2rboo+8cKp0O84pF4ff4v75hVwocf4dfvzbUg dLhFmxMjrAyQFQD6sQcJR8KaeRLw9FuC3J0k6qW/Fc1Oi6Qec3MmmXfujwBQXjnpkIpM 9U0xA3lIsFhmIWXSdm3RjCI6O/c4ebiC092+2IbWpozsuwLr9rdwBdTRpKvFyuYs8W4N PTcA== X-Gm-Message-State: AOAM531L1LJIITh8A1HNZzPr5zTqaCVDTzj1RWQWJlNEl0968uvxoFhp lU7ZBGXL0I0Ezs4kMCYUYP/wPQ== X-Google-Smtp-Source: ABdhPJyl+1yfgFUS4YuuskID0E4r3jxMJV3EP+gpOW8qxwgxQr3JeLBasBIfZBXK57mOkF0wiRRWBg== X-Received: by 2002:a17:903:288:b0:15f:4cc6:3195 with SMTP id j8-20020a170903028800b0015f4cc63195mr17620427plr.45.1652714082615; Mon, 16 May 2022 08:14:42 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id b12-20020a17090a5a0c00b001ded49491basm198821pjd.2.2022.05.16.08.14.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 May 2022 08:14:41 -0700 (PDT) Date: Mon, 16 May 2022 15:14:36 +0000 From: Sean Christopherson To: Maxim Levitsky Cc: Uros Bizjak , Peter Zijlstra , X86 ML , LKML , kvm@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Will Deacon , Boqun Feng , Mark Rutland , "Paul E. McKenney" , Marco Elver Subject: Re: [PATCH] locking/atomic/x86: Introduce try_cmpxchg64 Message-ID: References: <20220510154217.5216-1-ubizjak@gmail.com> <20220510165506.GP76023@worktop.programming.kicks-ass.net> <20220511075409.GX76023@worktop.programming.kicks-ass.net> <9ed2fc294bf2c21b41b22605ff8039bb71903712.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ed2fc294bf2c21b41b22605ff8039bb71903712.camel@redhat.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, May 16, 2022, Maxim Levitsky wrote: > On Mon, 2022-05-16 at 14:08 +0000, Sean Christopherson wrote: > > On Mon, May 16, 2022, Maxim Levitsky wrote: > > > On Wed, 2022-05-11 at 21:54 +0200, Uros Bizjak wrote: > > > > On Wed, May 11, 2022 at 6:04 PM Sean Christopherson wrote: > > > > > On Wed, May 11, 2022, Uros Bizjak wrote: > > > > > > On Wed, May 11, 2022 at 9:54 AM Peter Zijlstra wrote: > > > > > > > Still, does 32bit actually support that stuff? > > > > > > > > > > > > Unfortunately, it does: > > > > > > > > > > > > kvm-intel-y += vmx/vmx.o vmx/vmenter.o vmx/pmu_intel.o vmx/vmcs12.o \ > > > > > > vmx/evmcs.o vmx/nested.o vmx/posted_intr.o > > > > > > > > > > > > And when existing cmpxchg64 is substituted with cmpxchg, the > > > > > > compilation dies for 32bits with: > > > > > > > > > > ... > > > > > > > > > > > > Anyway, your patch looks about right, but I find it *really* hard to > > > > > > > care about 32bit code these days. > > > > > > > > > > > > Thanks, this is also my sentiment, but I hope the patch will enable > > > > > > better code and perhaps ease similar situation I have had elsewhere. > > > > > > > > > > IMO, if we merge this it should be solely on the benefits to 64-bit code. Yes, > > > > > KVM still supports 32-bit kernels, but I'm fairly certain the only people that > > > > > run 32-bit KVM are KVM developers. 32-bit KVM has been completely broken for > > > > > multiple releases at least once, maybe twice, and no one ever complained. > > > > > > > > Yes, the idea was to improve cmpxchg64 with the implementation of > > > > try_cmpxchg64 for 64bit targets. However, the issue with 32bit targets > > > > stood in the way, so the effort with 32-bit implementation was mainly > > > > to unblock progression for 64-bit targets. > > > > > > Would that allow tdp mmu to work on 32 bit? > > > > From a purely technical perspective, there's nothing that prevents enabling the > > TDP MMU on 32-bit kernels. The TDP MMU is 64-bit only to simplify the implementation > > and to reduce the maintenance and validation costs. > > I understand exactly that, so the question, will this patch help make the tdp > mmu work transparently on 32 bit kernels? I heard that 64 bit cmpxchg was > one of the main reasons that it is 64 bit only. I don't think it moves the needled much, e.g. non-atomic 64-bit accesses are still problematic, and we'd have to update the TDP MMU to deal with PAE paging (thanks NPT). All those problems are solvable, it's purely a matter of the ongoing costs to solve them. > I am asking because there was some talk to eliminate the direct mode from the > legacy non tdp mmu, which would simplify its code by a lot, but then it will > make 32 bit kernel fail back to shadowing mmu. Simplify which code? Between the nonpaging code and direct shadow pages in indirect MMUs, the vast majority of the "direct" support in the legacy MMU needs to be kept even if TDP support is dropped. And the really nasty stuff, e.g. PAE roots, would need to be carried over to the TDP MMU.