Received: by 10.213.65.68 with SMTP id h4csp1582455imn; Thu, 15 Mar 2018 04:03:32 -0700 (PDT) X-Google-Smtp-Source: AG47ELsdAMq8F0q3lC58FUn0lo0C+1mrfigS4q/Joi2OMYpeYkUXJNolUynUkr63NyuW3rjie3fe X-Received: by 10.98.50.130 with SMTP id y124mr7326640pfy.147.1521111812845; Thu, 15 Mar 2018 04:03:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521111812; cv=none; d=google.com; s=arc-20160816; b=OQAiBNQiar8CeOlucFjYnc3+C66XXzFMZyKHEizLcjGXwEehHD8akVBzJJHTPHteaN TJjpS14a+HMBXRQt1pWQyC5Lqc4xz8VNcI3sQaDjh2kS5PBQNLImZEWz994Y0+8l+8y6 Pw98uO0BAbrmuz0siFJCD17KMQXUjGLucyQr49eaaqng9o8kEZurVXuZ+/xOqoPhPJnA /hrLlsAcOm7zXBkS728sUloBfa7FRJrTUcgvAPw+2l43cV0zcum0c8DvpcFauZXGcc4e eGp/b37/1YrJ3vCwfEF+/qeYg2aCT29G7xykvOTqldxs/YftGtmlNH/+2c2p33j2Y0PP 1HiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=4rh3LXCPg143a77OwtzJ1gCuBeDNuQTsqM/vABoz9GY=; b=Vp56MbWpDUMyO9oyZ+IeY6I4ay6ZNGI0KA66oWTR3srLi6m91yjDKIkVo0ScfRbLDC FVbjlAYRaHMxAkh8+KGIragz3dUWVrBlk+eevhBKNzLAzrqw/SfdT9y5F43d9yz1Dh8z D6P9hGTkDXD+bp95U57Foa8HWf/NgF+yvNJT+GJ1Gfcj5pfFMn0FvDIYGNXgC6Z+MQBZ M1qwx7aw7TK+Y2GucYRrLo+JK3sDXFXa9fIm6bGibvyxI/WVJxQ3IPPVxCK6QSKYm0WY hgdYjaBkw9R29V6VwEVjxY5dQZOcpHTwqDXEnX/YCPxaULc+8QcT4RS3BGzbQfOz9DLM RBlg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b4-v6si3905676plk.262.2018.03.15.04.03.17; Thu, 15 Mar 2018 04:03:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752150AbeCOLB7 (ORCPT + 99 others); Thu, 15 Mar 2018 07:01:59 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:37050 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751617AbeCOLBb (ORCPT ); Thu, 15 Mar 2018 07:01:31 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B7052404085A; Thu, 15 Mar 2018 11:01:30 +0000 (UTC) Received: from [10.36.117.246] (ovpn-117-246.ams2.redhat.com [10.36.117.246]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3F603202322B; Thu, 15 Mar 2018 11:01:28 +0000 (UTC) Subject: Re: [PATCH v3 7/7] x86/kvm: use Enlightened VMCS when running on Hyper-V To: Vitaly Kuznetsov Cc: kvm@vger.kernel.org, x86@kernel.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , "Michael Kelley (EOSG)" , Mohammed Gamal , Cathy Avery , Bandan Das , linux-kernel@vger.kernel.org References: <20180309140249.2840-1-vkuznets@redhat.com> <20180309140249.2840-8-vkuznets@redhat.com> <2747cc75-b549-61bb-9c1b-0f554a49b536@redhat.com> <87fu51br1p.fsf@vitty.brq.redhat.com> From: Paolo Bonzini Message-ID: <02490491-9809-0057-fd4b-b1de81c713f3@redhat.com> Date: Thu, 15 Mar 2018 12:01:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <87fu51br1p.fsf@vitty.brq.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Thu, 15 Mar 2018 11:01:30 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Thu, 15 Mar 2018 11:01:30 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'pbonzini@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/03/2018 10:56, Vitaly Kuznetsov wrote: >> + EVMCS1_FIELD(VM_EXIT_MSR_STORE_ADDR, vm_exit_msr_store_addr, >> + HV_VMX_ENLIGHTENED_CLEAN_FIELD_ALL), >> + EVMCS1_FIELD(VM_EXIT_MSR_LOAD_ADDR, vm_exit_msr_load_addr, >> + HV_VMX_ENLIGHTENED_CLEAN_FIELD_ALL), >> + EVMCS1_FIELD(VM_ENTRY_MSR_LOAD_ADDR, vm_entry_msr_load_addr, >> + HV_VMX_ENLIGHTENED_CLEAN_FIELD_ALL), >> + EVMCS1_FIELD(VM_EXIT_MSR_STORE_COUNT, vm_exit_msr_store_count, >> + HV_VMX_ENLIGHTENED_CLEAN_FIELD_ALL), >> + EVMCS1_FIELD(VM_EXIT_MSR_LOAD_COUNT, vm_exit_msr_load_count, >> + HV_VMX_ENLIGHTENED_CLEAN_FIELD_ALL), >> + EVMCS1_FIELD(VM_ENTRY_MSR_LOAD_COUNT, vm_entry_msr_load_count, >> + HV_VMX_ENLIGHTENED_CLEAN_FIELD_ALL), Hmm, actually these six are used. I guess HV_VMX_ENLIGHTENED_CLEAN_FIELD_ALL is the best we can do, apart from asking Microsoft to fix the spec. >>> +{ >>> + *pin_based_exec_ctrl &= ~PIN_BASED_POSTED_INTR;> + *cpu_based_2nd_exec_ctrl &= ~SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY; >>> + *cpu_based_2nd_exec_ctrl &= ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES; >>> + *cpu_based_2nd_exec_ctrl &= ~SECONDARY_EXEC_APIC_REGISTER_VIRT; >>> + *cpu_based_2nd_exec_ctrl &= ~SECONDARY_EXEC_ENABLE_PML; >>> + *cpu_based_2nd_exec_ctrl &= ~SECONDARY_EXEC_ENABLE_VMFUNC; >>> + *cpu_based_2nd_exec_ctrl &= ~SECONDARY_EXEC_SHADOW_VMCS; >>> + *cpu_based_2nd_exec_ctrl &= ~SECONDARY_EXEC_TSC_SCALING; >>> + *cpu_based_2nd_exec_ctrl &= ~SECONDARY_EXEC_PAUSE_LOOP_EXITING; >>> + *pin_based_exec_ctrl &= ~PIN_BASED_VMX_PREEMPTION_TIMER; >> How can these be set? >> > They can not if Hyper-V behaves but Radim didn't want to trust it -- so > the suggestion was to forcefully disable unsupported controls. Yeah, it's good to have, especially if placed before we start using the values that are read. >> This is wrong, we're reading the VMCS so the values must already be >> sanitized (and if not, that's the bug and we want dump_vmcs to print the >> "wrong" values). > > The problem is that we vmcs_read these fields later in the function and > this will now WARN(). Initally, there was no WARN() for non-existent > fields so this could work (we would just print zeroes for unsupported > fields). Maybe, additional WARN_ON() is not a big deal here. If you WARN(), isn't it because the secondary_exec_control had a bad value to begin with? As you say, the controls should never be set. Thanks, Paolo