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 0EAB5C433EF for ; Thu, 20 Jan 2022 01:06:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345719AbiATBGe (ORCPT ); Wed, 19 Jan 2022 20:06:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345578AbiATBGd (ORCPT ); Wed, 19 Jan 2022 20:06:33 -0500 Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77543C06161C for ; Wed, 19 Jan 2022 17:06:33 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id e9so664847pgn.4 for ; Wed, 19 Jan 2022 17:06:33 -0800 (PST) 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:content-transfer-encoding:in-reply-to; bh=Cn8y2MduSfxpaUqgG70M6OfS7ciqUGnpG7newRRVGPo=; b=l9//kvAqzr4TuZQOO5YZKMU5K+Nz/XqA2W8mABc4KeB0yGrfqBBq4kx2YfXYRGnmr6 U27+GMDDLWM+9p1myl0pCQNxtGLVjmwRvs7Q58qRhTHaNtAbqWG7kF3z1/TXbFni3YQx BKZXCgPFF54pw4BZTc8lZvGrjxCHFz3eRBg5IjXWkiZ7qSdDgjBKujwCswcM7n+ftqli qzk/694Fo7qKRGCoEb5H+i0aMcf8iDbIjutDmDpYDN11368ebUpJUC8oMadzTD0s766P MluaYOSWQlvvG/YRm0yfhQK1z/go8/OpbmPHDk7XKforxsXh6aM2m/YPHRnEkd4BBbae 1a9Q== 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:content-transfer-encoding :in-reply-to; bh=Cn8y2MduSfxpaUqgG70M6OfS7ciqUGnpG7newRRVGPo=; b=ijLGtHm6Nk4XC3roaF+CZTBGLeK8qQ1/0YLvX5C9ngUd3FuyX/nSwJGiJemQsSAm7X 8+LydUMyTxu0QYP8IKnJN3u9xaxo7AckmJgluC5wMhDb/f3J1r9xpbsWWr7oliWoHUh1 WLCirpzpgnqAiIlsrOyEyeoiZyigTmoSvqAQFIP3Z1ZfRJpyBkmX/aOQVq2Uqpoxf5bg DSR2DC9akd8uF1P/mqN53F5kslK8ORyT/pxgi8KVq/YhnqjcT+Hwtfd3a72350lW+cCI 99z6ybn7S0eupfe1Nh1j4aCKDnykEuphxJhlCiVUcfKeXa8EIhqJXzhqCiaUIrjKuj7B YIxg== X-Gm-Message-State: AOAM5318jWhBPfUYBXaJ94Af2yCmpxGqk9Iht+nhWtjEM8w6qh52icV+ Pa+3kLF5Nz10kk9QRoCAYlX+rg== X-Google-Smtp-Source: ABdhPJwhpHGT8KOOuEPAQImew6soTRUO2yMGEdyts2hB/E1RwOriB5vWheLq4HUU+aewl1urvRc1oA== X-Received: by 2002:a63:fe10:: with SMTP id p16mr29143931pgh.546.1642640792646; Wed, 19 Jan 2022 17:06:32 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id m17sm843462pfk.62.2022.01.19.17.06.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jan 2022 17:06:31 -0800 (PST) Date: Thu, 20 Jan 2022 01:06:28 +0000 From: Sean Christopherson To: Zeng Guang Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , "kvm@vger.kernel.org" , Dave Hansen , "Luck, Tony" , Kan Liang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Kim Phillips , Jarkko Sakkinen , Jethro Beekman , "Huang, Kai" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "Hu, Robert" , "Gao, Chao" , Robert Hoo Subject: Re: [PATCH v5 4/8] KVM: VMX: dump_vmcs() reports tertiary_exec_control field as well Message-ID: References: <20211231142849.611-1-guang.zeng@intel.com> <20211231142849.611-5-guang.zeng@intel.com> <7fd4cb11-9920-6432-747e-633b96db0598@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7fd4cb11-9920-6432-747e-633b96db0598@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 14, 2022, Zeng Guang wrote: > On 1/14/2022 5:03 AM, Sean Christopherson wrote: > > Can you provide a sample dump? It's hard to visualize the output, e.g. I'm worried > > this will be overly log and harder to read than putting tertiary controls on their > > own line. > > Sample dump here. > *** Control State *** > >  PinBased=0x000000ff CPUBased=0xb5a26dfa SecondaryExec=0x061037eb > TertiaryExec=0x0000000000000010 That's quite the line. What if we reorganize the code to generate output like: CPUBased=0xb5a26dfa SecondaryExec=0x061037eb TertiaryExec=0x0000000000000010 PinBased=0x000000ff EntryControls=0000d1ff ExitControls=002befff That keeps the lines reasonable and IMO is better organization too, e.g. it captures the relationship between primary, secondary, and tertiary controls. >  EntryControls=0000d1ff ExitControls=002befff >  ExceptionBitmap=00060042 PFECmask=00000000 PFECmatch=00000000 >  VMEntry: intr_info=00000000 errcode=00000000 ilen=00000000 >  VMExit: intr_info=00000000 errcode=00000000 ilen=00000003 >          reason=00000030 qualification=0000000000000784 > > > pr_err("EntryControls=%08x ExitControls=%08x\n", vmentry_ctl, vmexit_ctl); > > > pr_err("ExceptionBitmap=%08x PFECmask=%08x PFECmatch=%08x\n", > > > vmcs_read32(EXCEPTION_BITMAP), > > > -- > > > 2.27.0 > > >