Received: by 2002:a19:f614:0:0:0:0:0 with SMTP id x20csp34216lfe; Fri, 15 Apr 2022 18:08:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzAtNgIqiquejqkmre3mHgPYLp+BJBmkbZKNF91Icrizb2lMI6af2eWY2OoyfD/QXERm9Pv X-Received: by 2002:a17:90a:6c64:b0:1cb:93b2:b6a9 with SMTP id x91-20020a17090a6c6400b001cb93b2b6a9mr7026524pjj.144.1650071297011; Fri, 15 Apr 2022 18:08:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650071297; cv=none; d=google.com; s=arc-20160816; b=A/1f6GjHrwt9QFMJDXBL5WcVxNRqYAjs/882RXdI0EaJEAlTUe4+tYw3zyYGlNpr+N RYPUEt0Et981gy3WEPBiDK1ppBrS706riO+RXCcyhxlkfU0TaztYWefJxgWqzanlrJj9 DJOtmdMol1+lBR1GzfHiFLQC46txLl8+u3Lo4RgGFlyPeO7cOhm1I5ALfLvJegWYCW7K DqiYdLOBMs4f7XWzObAi5Y1kdMB29bW2QHju9ewdCi1A4PIOIWle2TOzXFj4bWKCAEak UJeZP2EyxGjat3V33z/rp03qGAu40/5AScp+YrxNcgAeAMJR8WktBzt/dZzWA9rqrZ9z 0NUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=+y0rTsN9NYq4kk+FFTr/ajEtcI961W4Mxu4oUxgLxck=; b=KmMwvruQLf30hDs4lfxkI49DVu+bpJ6V6qPC8OSnZLgLDUhb/BunjtWiCOAz0G+gms MBBkNntCnV2ubfF/TLgmpm2UMMIBJ36q6e+n5sClkVwO7ZZHQ7oWNXgd5UFYU02ZiMyv o9XBNASFq6+I65PPDGTNKf1cqR/DCtChYDAck7echhW69cw1NOK44LN2FEJklNEpWPNG rARYGag6mB+NDmo+wnt/ixrlZhcK+BLgwcmizHoWDp4V8T2DLGakmRhbDu7/bB97DQ5A hdtvs3MjkTc+Tg9GMCXn82agT2hMcFD5c7SQajTXktS8Pvrs8gtuZRvnTrh20E6DT351 81kA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=MbMYpQoF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id h6-20020aa79f46000000b004fa3a8e0003si2635414pfr.186.2022.04.15.18.08.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 18:08:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=MbMYpQoF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 66EF7129857; Fri, 15 Apr 2022 17:48:33 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343721AbiDNVhS (ORCPT + 99 others); Thu, 14 Apr 2022 17:37:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230438AbiDNVhR (ORCPT ); Thu, 14 Apr 2022 17:37:17 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4AC66673F2 for ; Thu, 14 Apr 2022 14:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649972089; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+y0rTsN9NYq4kk+FFTr/ajEtcI961W4Mxu4oUxgLxck=; b=MbMYpQoFDmF9MBsW2Nh2sFZNR/zrp47NLeSFb0ibMffBijDI2jqGnX0bmEXfuE+6P55nAT xs8McMV9h31BvSYIfO4mF+gVNOzNzK2S72zHDRU+7gFjGpsnSABjUewav/1E7Z4AUEwPTO n9G2LPgV1VxRVbUFKlnsFudeVYzgeaw= Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-203-yv0bw-JKOEmuUcxmqaOaMw-1; Thu, 14 Apr 2022 17:34:48 -0400 X-MC-Unique: yv0bw-JKOEmuUcxmqaOaMw-1 Received: by mail-il1-f200.google.com with SMTP id i2-20020a056e021d0200b002cac9b3b46cso3759096ila.5 for ; Thu, 14 Apr 2022 14:34:48 -0700 (PDT) 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=+y0rTsN9NYq4kk+FFTr/ajEtcI961W4Mxu4oUxgLxck=; b=hd4ofT0CpLZ1CAu7UXFNGe0XZG0eE4DOkW9k4RIOQ6LY9rcVlJzwXU/kU6tYhMrDKW xVwaHb0H9wzT/FY9Vr7EE+43ViGzZ91DYTHPFLBm6CTkDOGjOBuoBk0XhymmfhroCGIa zRkkw5EY+uCFSCRMb0IpcT+wxt2n39Vplo/MqdUJiq9tJzmhbeOBoFFoqAzj81wfz9T0 uYlnrPIIBhbzrNZyxRgX5Hsi308J3THfygW/byk5syRIK9G14e5wFBW4+A7nSBoxukrx jc0suaMCP1kIncSQ2NGvWrxgIUyLy7fJjpSvi6+yDJntreyS1ZMy6rpnc8OxX7gx4tb1 nKSQ== X-Gm-Message-State: AOAM531hFzg6Bx2+eAZcIUTzRqCYEsfYmpf49zu649vaf8baJH7aD881 hN5wbeywBOVcBvqtspsp02oHui4tQ3dAB15FFiJhckdlZguEz6ZOwpY+P6HBjNu1F97NQN6ier3 vslr8uKgFTYnSS/YriEyU6yIx X-Received: by 2002:a05:6638:268a:b0:326:6fab:af6 with SMTP id o10-20020a056638268a00b003266fab0af6mr2056939jat.280.1649972087658; Thu, 14 Apr 2022 14:34:47 -0700 (PDT) X-Received: by 2002:a05:6638:268a:b0:326:6fab:af6 with SMTP id o10-20020a056638268a00b003266fab0af6mr2056928jat.280.1649972087404; Thu, 14 Apr 2022 14:34:47 -0700 (PDT) Received: from xz-m1.local (cpec09435e3e0ee-cmc09435e3e0ec.cpe.net.cable.rogers.com. [99.241.198.116]) by smtp.gmail.com with ESMTPSA id e4-20020a056e020b2400b002ca9ffbb8fesm1825796ilu.72.2022.04.14.14.34.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Apr 2022 14:34:47 -0700 (PDT) Date: Thu, 14 Apr 2022 17:34:45 -0400 From: Peter Xu To: Paolo Bonzini Cc: Sean Christopherson , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Ben Gardon , David Matlack , Andrew Jones Subject: Re: [PATCH] kvm: selftests: Fix cut-off of addr_gva2gpa lookup Message-ID: References: <20220414010703.72683-1-peterx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 14, 2022 at 04:14:22PM +0200, Paolo Bonzini wrote: > On 4/14/22 15:56, Sean Christopherson wrote: > > > - return (pte[index[0]].pfn * vm->page_size) + (gva & 0xfffu); > > > + return ((vm_paddr_t)pte[index[0]].pfn * vm->page_size) + (gva & 0xfffu); > > This is but one of many paths that can get burned by pfn being 40 bits. The > > most backport friendly fix is probably to add a pfn=>gpa helper and use that to > > place the myriad "pfn * vm->page_size" instances. > > > > For a true long term solution, my vote is to do away with the bit field struct > > and use #define'd masks and whatnot. > > Yes, bitfields larger than 32 bits are a mess. It's very interesting to know this.. I just tried out with <32 bits bitfield and indeed gcc will behave differently, by having the calculation done with 32bit (eax) rather than 64bit (rax). The question is for >=32 bits it needs an extra masking instruction, while that does not exist for the <32bits bitfield. ---8<--- #include struct test1 { unsigned long a:${X}; unsigned long b:10; }; int main(void) { struct test1 val; val.a = 0x1234; printf("0x%lx\n", val.a * 16); return 0; } ---8<--- When X=20: 0000000000401126
: 401126: 55 push %rbp 401127: 48 89 e5 mov %rsp,%rbp 40112a: 48 83 ec 10 sub $0x10,%rsp 40112e: 8b 45 f8 mov -0x8(%rbp),%eax 401131: 25 00 00 f0 ff and $0xfff00000,%eax 401136: 0d 34 12 00 00 or $0x1234,%eax 40113b: 89 45 f8 mov %eax,-0x8(%rbp) 40113e: 8b 45 f8 mov -0x8(%rbp),%eax 401141: 25 ff ff 0f 00 and $0xfffff,%eax 401146: c1 e0 04 shl $0x4,%eax <----------- calculation (no further masking) 401149: 89 c6 mov %eax,%esi 40114b: bf 10 20 40 00 mov $0x402010,%edi 401150: b8 00 00 00 00 mov $0x0,%eax 401155: e8 d6 fe ff ff callq 401030 When X=40: 0000000000401126
: 401126: 55 push %rbp 401127: 48 89 e5 mov %rsp,%rbp 40112a: 48 83 ec 10 sub $0x10,%rsp 40112e: 48 8b 45 f8 mov -0x8(%rbp),%rax 401132: 48 ba 00 00 00 00 00 movabs $0xffffff0000000000,%rdx 401139: ff ff ff 40113c: 48 21 d0 and %rdx,%rax 40113f: 48 0d 34 12 00 00 or $0x1234,%rax 401145: 48 89 45 f8 mov %rax,-0x8(%rbp) 401149: 48 b8 ff ff ff ff ff movabs $0xffffffffff,%rax 401150: 00 00 00 401153: 48 23 45 f8 and -0x8(%rbp),%rax 401157: 48 c1 e0 04 shl $0x4,%rax <------------ calculation 40115b: 48 ba ff ff ff ff ff movabs $0xffffffffff,%rdx 401162: 00 00 00 401165: 48 21 d0 and %rdx,%rax <------------ masking (again) 401168: 48 89 c6 mov %rax,%rsi 40116b: bf 10 20 40 00 mov $0x402010,%edi 401170: b8 00 00 00 00 mov $0x0,%eax 401175: e8 b6 fe ff ff callq 401030 That feels a bit less consistent to me, comparing to clang where at least the behavior keeps the same for whatever length of bits in the bitfields. Thanks, -- Peter Xu