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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9DB1CC31E5C for ; Tue, 18 Jun 2019 02:40:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7D1222085A for ; Tue, 18 Jun 2019 02:40:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726723AbfFRCkX (ORCPT ); Mon, 17 Jun 2019 22:40:23 -0400 Received: from mga14.intel.com ([192.55.52.115]:46433 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725829AbfFRCkX (ORCPT ); Mon, 17 Jun 2019 22:40:23 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2019 19:40:22 -0700 X-ExtLoop1: 1 Received: from txu2-mobl.ccr.corp.intel.com (HELO [10.239.196.224]) ([10.239.196.224]) by orsmga003.jf.intel.com with ESMTP; 17 Jun 2019 19:40:19 -0700 Subject: Re: [PATCH RESEND v3 2/3] KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Xiaoyao Li Cc: pbonzini@redhat.com, corbet@lwn.net, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, sean.j.christopherson@intel.com, fenghua.yu@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, jingqi.liu@intel.com References: <20190616095555.20978-1-tao3.xu@intel.com> <20190616095555.20978-3-tao3.xu@intel.com> <20190617155038.GA13955@flask> From: Tao Xu Message-ID: Date: Tue, 18 Jun 2019 10:40:18 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <20190617155038.GA13955@flask> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 6/17/2019 11:50 PM, Radim Krčmář wrote: > 2019-06-17 14:31+0800, Xiaoyao Li: >> On 6/17/2019 11:32 AM, Xiaoyao Li wrote: >>> On 6/16/2019 5:55 PM, Tao Xu wrote: >>>> +    if (vmx->msr_ia32_umwait_control != host_umwait_control) >>>> +        add_atomic_switch_msr(vmx, MSR_IA32_UMWAIT_CONTROL, >>>> +                      vmx->msr_ia32_umwait_control, >>>> +                      host_umwait_control, false); >>> >>> The bit 1 is reserved, at least, we need to do below to ensure not >>> modifying the reserved bit: >>> >>>     guest_val = (vmx->msr_ia32_umwait_control & ~BIT_ULL(1)) | >>>             (host_val & BIT_ULL(1)) >>> >> >> I find a better solution to ensure reserved bit 1 not being modified in >> vmx_set_msr() as below: >> >> if((data ^ umwait_control_cached) & BIT_ULL(1)) >> return 1; > > We could just be checking > > if (data & BIT_ULL(1)) > > because the guest cannot change its visible reserved value and KVM > currently initializes the value to 0. > > The arch/x86/kernel/cpu/umwait.c series assumes that the reserved bit > is 0 (hopefully deliberately) and I would do the same in KVM as it > simplifies the logic. (We don't have to even think about migrations > between machines with a different reserved value and making it play > nicely with possible future implementations of that bit.) > > Thanks. > Thank you Radim and xiaoyao's review, I will improve it in the next version. Xiaoyao's suggestion remind me another thing. And I am wondering if we need to initialize the value of MSR_IA32_UMWAIT_CONTROL in KVM to 0x186a0(umwait_control = 100000, as host does). Although the guest with new kernel(has umwait host patch)can initialize the value to 0x186a0. But there is a case that a guest with a old kernel and the host with the new kernel and has the cpuid of WAITPKG. Because the msr value is 0, the guest umwait will have no max time by default.