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 4FAA4CCA479 for ; Thu, 14 Jul 2022 00:52:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230507AbiGNAwb (ORCPT ); Wed, 13 Jul 2022 20:52:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229495AbiGNAw3 (ORCPT ); Wed, 13 Jul 2022 20:52:29 -0400 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6AF0E12D14 for ; Wed, 13 Jul 2022 17:52:28 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id e16so455025pfm.11 for ; Wed, 13 Jul 2022 17:52:28 -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=H4muTwTgTj/3OhnwCnsvELB7YAIn9AMy7WICw3/QJ4w=; b=DZ0JsVJaoBMRYe7xi/4MtG11T2qpS+rcVen/o5oYAJBWsYnQe6mluRAmiel0TmHCNB GIWXyVWINduz3/4fpvL1o0Qyazayyj7YpCQ5KpNuI90jGAmjEXCXhGorB8viqm9zIsho u7gmktA3rbS6kCc8mTP+2WS7DexOgtfmu1lPTG25pNUysEFZpuYtkWnfwuPCoGhalbgX 4MvXSMqV7cfMOTHqeWB9GLdJb/U0GQANzfvqDgIyVP18RJYBeYUzLhTLoCHcWd3rpDEH hkuPFgVStsZc/X2C/Wye3q0bjnW5mngZKBEHwHl4pO4q6nR5tu891xEL2AIDSBVDZ12L F1IA== 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=H4muTwTgTj/3OhnwCnsvELB7YAIn9AMy7WICw3/QJ4w=; b=pxOZhGJXwRQJoNP+PBevDtF1osXABimMhWF4Wy2zQ8Ee/ePkzL0TxpO4JQqmKKpo8i k0zwXpglx2fJbNnhlaNl0Fk4K+yx0jKGZeiKI0KiEe6j4JNjaVPtt78TZSDeoRWoE8yW 8aFD8Xbk+VZgMQEJXAqoe6ogTdbQWwqTr/9tw2kdOEWJGwvx75mS914OZ4grfh2Qb7gZ 2B7w1EWDqeFXTVaqqVFaCgbYp68X95c+i4KjsGyilzrM5sYh3TXgyMO/4DWe/66pag77 4LLITELoHyNbwHcL+pA09W3gS8cf4+tq0298PfUoXsHDMgCFJ6tngKvjzGmE1VHdpFZc 7S7g== X-Gm-Message-State: AJIora8m/bjbMGgZOXdQIrvryH6B4FkcdW1Wsj/jbuILHb/xZ/EdtYit EbGxH4sTzew1mN6WV7sCeVfUTQ== X-Google-Smtp-Source: AGRyM1vfTV94aQO3q8/sedYOGeQM5m9Kb1aEJf1L6HYk2kAOq5ucZILxkJ41cMvtYV7fdO7dP8z9OA== X-Received: by 2002:a05:6a00:2189:b0:52b:86c:26cc with SMTP id h9-20020a056a00218900b0052b086c26ccmr5735373pfi.44.1657759947798; Wed, 13 Jul 2022 17:52:27 -0700 (PDT) Received: from google.com (123.65.230.35.bc.googleusercontent.com. [35.230.65.123]) by smtp.gmail.com with ESMTPSA id l13-20020a170903120d00b0016bedecdd65sm42055plh.159.2022.07.13.17.52.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Jul 2022 17:52:27 -0700 (PDT) Date: Thu, 14 Jul 2022 00:52:23 +0000 From: Sean Christopherson To: Vitaly Kuznetsov Cc: kvm@vger.kernel.org, Paolo Bonzini , Wanpeng Li , Jim Mattson , Maxim Levitsky , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] KVM: selftests: Fix wrmsr_safe() Message-ID: References: <20220713150532.1012466-1-vkuznets@redhat.com> <20220713150532.1012466-3-vkuznets@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 13, 2022, Sean Christopherson wrote: > On Wed, Jul 13, 2022, Vitaly Kuznetsov wrote: > > It seems to be a misconception that "A" places an u64 operand to > > EAX:EDX, at least with GCC11. > > It's not a misconception, it's just that the "A" trick only works for 32-bit > binaries. For 64-bit, the 64-bit integer fits into "rax" without needing to spill > into "rdx". > > I swear I had fixed this, but apparently I had only done that locally and never > pushed/posted the changes :-/ Ugh, I have a feeling I fixed RDMSR and then forgot about WRSMR. > > While writing a new test, I've noticed that wrmsr_safe() tries putting > > garbage to the upper bits of the MSR, e.g.: > > > > kvm_exit: reason MSR_WRITE rip 0x402919 info 0 0 > > kvm_msr: msr_write 40000118 = 0x60000000001 (#GP) > > ... > > when it was supposed to write '1'. Apparently, "A" works the same as > > "a" and not as EAX/EDX. Here's the relevant disassembled part: > > > > With "A": > > > > 48 8b 43 08 mov 0x8(%rbx),%rax > > 49 b9 ba da ca ba 0a movabs $0xabacadaba,%r9 > > 00 00 00 > > 4c 8d 15 07 00 00 00 lea 0x7(%rip),%r10 # 402f44 > > 4c 8d 1d 06 00 00 00 lea 0x6(%rip),%r11 # 402f4a > > 0f 30 wrmsr > > > > With "a"/"d": > > > > 48 8b 43 08 mov 0x8(%rbx),%rax > > 48 89 c2 mov %rax,%rdx > > 48 c1 ea 20 shr $0x20,%rdx Huh. This is wrong. RAX is loaded with the full 64-bit value. It doesn't matter for WRMSR because WRMSR only consumes EAX, but it's wrong. I can't for the life of me figure out why casting to a u32 doesn't force the compiler to truncate the value. Truncation in other places most definitely works, and the compiler loads only EAX and EDX when using a hardcoded value, e.g. -1ull, so the input isn't messed up. There's no 32-bit loads of EAX, so no implicit truncation of RAX[63:32]. gcc-{7,9,11} and clang-13 generate the same code, so either it's a really longstanding bug, or maybe some funky undocumented behavior? If I use return kvm_asm_safe("wrmsr", "a"(val & -1u), "d"(val >> 32), "c"(msr)); then the result is as expected: 48 8b 53 08 mov 0x8(%rbx),%rdx 89 d0 mov %edx,%eax 48 c1 ea 20 shr $0x20,%rdx I'll post a v2 of just this patch on your behalf, I also reworded the changelog to include the gcc documentation that talks about the behavior of "A".