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 2AAD6C4332F for ; Tue, 1 Nov 2022 17:26:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230143AbiKAR0d (ORCPT ); Tue, 1 Nov 2022 13:26:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230092AbiKAR0b (ORCPT ); Tue, 1 Nov 2022 13:26:31 -0400 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4035B1A21B for ; Tue, 1 Nov 2022 10:26:31 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id o7so10658489pjj.1 for ; Tue, 01 Nov 2022 10:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=A4QtUNj00AFef6/SLaxc9/EwfiEMk/XY7VysTIRCNPk=; b=GsJToAMuJ29wa7MEmx4mYyei/7wv80A0LVzK56seJd3rF4Iza7U3ZPb2voZV21TLTN RxpDgA2RSMWks/aF2G1p1yac9G/1umJFalIjnM0nXDpvs8UOdNk7V54bFdBfr34nX38e IQXZHEYQL81ulw6Uymt/PPeYXF0F3z62tB5HDbR5bjJHaCzZOtdxavohIZJCCqGp8dq3 lWca2/vOzct4CEreWPEW2kTLPa1KAz6yPdkGtc+Nyc71IcwQcGBbEb8l8yakRNIBUKEn 9YvwySYx/6EYUSNoFfcEHRtZd7HxydbrpvsFNsDcM6LomZIXAmeUXQpZo3bOdnz84whe TtaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=A4QtUNj00AFef6/SLaxc9/EwfiEMk/XY7VysTIRCNPk=; b=yt3ozMD7FYY4eHJKrSAhfGStpaPAevNPSsV4U4NsO45ubrs9O9vvFWVM3KJQS9ZMXe HEO4j4Ew2/htwR9LheP2E1RCCYd/cMhNagMwnr+fl9cM0gmmAnndNDAGNi0RhvUhILks budy4ubxU08agFnyOQGuPPo8vCMhLihO7box+c8JNibylPlvwIXlgkrbA1mSpWDb4KQZ 8IYQ6WhUXZwp7HwbuN0IPZ4fQttxzrZbSqlMr/CAHWqE+4b2aBshS1HiMSZ81YdRpYr6 x4oYLOtyiqGnksdnIbuT0AvtVv28LpA8bxH46qIV5P653+Yqm5SAyHaBswJFIuCLbQmk 0UNg== X-Gm-Message-State: ACrzQf2AJndIoprpC6om7FUJB9zLRA/8D6QQ5P1ajbJkD27n+Mlexs5n 3n1xbXXmbZxxz7hqSHOzd32e+A== X-Google-Smtp-Source: AMsMyM5Vb6UFf34QgXTQptO3wBNpsNlppGWrjixPl4a14JL9LAnJyPI67XMAeJtoT1oJDK1obuG8+g== X-Received: by 2002:a17:902:d54a:b0:186:a43b:8e with SMTP id z10-20020a170902d54a00b00186a43b008emr21216723plf.36.1667323590558; Tue, 01 Nov 2022 10:26:30 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id r7-20020aa79ec7000000b0056da63c8515sm2984440pfq.91.2022.11.01.10.26.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Nov 2022 10:26:30 -0700 (PDT) Date: Tue, 1 Nov 2022 17:26:26 +0000 From: Sean Christopherson To: Vitaly Kuznetsov Cc: kvm@vger.kernel.org, Paolo Bonzini , Wanpeng Li , Jim Mattson , Michael Kelley , Siddharth Chandrasekaran , Yuan Yao , Maxim Levitsky , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v13 45/48] KVM: selftests: Introduce rdmsr_from_l2() and use it for MSR-Bitmap tests Message-ID: References: <20221101145426.251680-1-vkuznets@redhat.com> <20221101145426.251680-46-vkuznets@redhat.com> <87bkpqskr2.fsf@ovpn-194-149.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bkpqskr2.fsf@ovpn-194-149.brq.redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org On Tue, Nov 01, 2022, Vitaly Kuznetsov wrote: > Sean Christopherson writes: > > > On Tue, Nov 01, 2022, Vitaly Kuznetsov wrote: > >> Hyper-V MSR-Bitmap tests do RDMSR from L2 to exit to L1. While 'evmcs_test' > >> correctly clobbers all GPRs (which are not preserved), 'hyperv_svm_test' > >> does not. Introduce and use common rdmsr_from_l2() to avoid code > >> duplication and remove hardcoding of MSRs. > >> > >> Signed-off-by: Vitaly Kuznetsov > >> --- > >> .../selftests/kvm/include/x86_64/processor.h | 9 +++++++ > >> .../testing/selftests/kvm/x86_64/evmcs_test.c | 24 ++++--------------- > >> .../selftests/kvm/x86_64/hyperv_svm_test.c | 8 +++---- > >> 3 files changed, 17 insertions(+), 24 deletions(-) > >> > >> diff --git a/tools/testing/selftests/kvm/include/x86_64/processor.h b/tools/testing/selftests/kvm/include/x86_64/processor.h > >> index fbaf0b6cec4b..a14b7e4ea7c4 100644 > >> --- a/tools/testing/selftests/kvm/include/x86_64/processor.h > >> +++ b/tools/testing/selftests/kvm/include/x86_64/processor.h > >> @@ -520,6 +520,15 @@ static inline void cpu_relax(void) > >> "hlt\n" \ > >> ) > >> > >> +/* Exit to L1 from L2 with RDMSR instruction */ > >> +static inline void rdmsr_from_l2(uint32_t msr) > > > > I would prefer keeping this helper out of common x86-64 code, even if it means > > duplicating code across multiple Hyper-V tests until the L1 VM-Enter/VM-Exit > > sequences get cleaned up. The name is misleading, e.g. it doesn't really read > > the MSR since there are no outputs > > It's somewhat similar to vmcall()/vmmcall() which are only used to exit > from L2 to L1 (and thus nobody complained that all the register values > are random) and not issue a hypercall and return some value. Sort of. VMCALL/VMMCALL are unique in that they have no meaning (ignoring VMX's STM) other than what is given to them by the hypervisor/software on VM-Exit. RDMSR on the other hand (and literally every other instruction), has architecturally defined behavior and thus expectations beyond generating a VM-Exit. I do think we should clean up the VMCALL/VMMCALL code to remove the clobbers if/when the VM-Enter/VM-Exit sequences are fixed, and maybe make them more generic, e.g. to allow reusing helpers for L1 and L2. But, because the meaning of VMCALL/VMMCALL is software-defined, we'll always need a selftests specific L2=>L1 hypercall, e.g. to ensure L0 forwards the hypercall to L1.