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=-8.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 E0A3DC433E6 for ; Mon, 8 Feb 2021 19:56:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 998C964DFF for ; Mon, 8 Feb 2021 19:56:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236516AbhBHT42 (ORCPT ); Mon, 8 Feb 2021 14:56:28 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:27799 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235211AbhBHSNy (ORCPT ); Mon, 8 Feb 2021 13:13:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612807948; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Em5Q6izKRwuYnxNNv2p6LEzG/SfeITVQD9/V+T5jR/M=; b=AuwqrnhytR+H7MDdRU82YX0yVC3tEWmtf8XESeYH+YDQfTJ63hu0ezRcF2Z/ae583/2Zb4 M0+uQYJaqARHwNpZijRIFfJqltst8kXPDbpKI6zkybkFZYZRGLKYaFI0eEhihmz/p92Jr4 +PqOqFJOzbLgUkqFgjmbr+cNz46FbD4= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-479-ZGIFpHUfNYKIMd6afTpH0w-1; Mon, 08 Feb 2021 13:12:25 -0500 X-MC-Unique: ZGIFpHUfNYKIMd6afTpH0w-1 Received: by mail-wm1-f72.google.com with SMTP id y9so9214935wmi.8 for ; Mon, 08 Feb 2021 10:12:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Em5Q6izKRwuYnxNNv2p6LEzG/SfeITVQD9/V+T5jR/M=; b=cQCBHkKHI748LmS4rSqZdWB0Ix6cUBDsRPccTINZvvw8sUH+9Mm0Tge0O7o0yvc9Fd nLmPwhWWjDsItdiJVFzU8SIi0yf7ytfI7qBfT1Kmf1R+E4qcq0Bbyu3smZQObAKkqtDC WpRCLO04nan7QtACr6cExhgXT6l9v9/ZmfE5FWxd0LeNUhkYb+QvqxG5FDpXaQo6vyhJ bg9HeqLf/VKHJ6hffZF73GHu57mPGtwzmmAHiSfSo8M2vvGFikmCGXJFjHA621Jh3HcQ 8Rax8Ju3tf8uuOaDOwGbmZOmif+Kjnn3oDJBInbsV/BoufS/J+cumZMEq06ZHQj2k3sz w/Aw== X-Gm-Message-State: AOAM530hFiMOU3Z9S1W2lnoE8vOWKlZ6SnulJs9tpcdb963wsu7Sm0qi 4VqtFvqdPmfNYL7F6XJtCr6Kn8UTM4Dg0L8EnvCKJ/ahphC7IQZxu7LEW3J2PWSnCh3jv3ye4O+ gsfWe4+AagjjCNIQTqfy4uoqq X-Received: by 2002:adf:b64f:: with SMTP id i15mr20465103wre.279.1612807944284; Mon, 08 Feb 2021 10:12:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJxWpAeK4msgOmM8v7VqEwvUaMXj+/R0pAL/O0nlqtcHUVclMsQXrcY9KuBLfX7dfzMQi4j5pA== X-Received: by 2002:adf:b64f:: with SMTP id i15mr20465080wre.279.1612807944075; Mon, 08 Feb 2021 10:12:24 -0800 (PST) Received: from ?IPv6:2001:b07:6468:f312:c8dd:75d4:99ab:290a? ([2001:b07:6468:f312:c8dd:75d4:99ab:290a]) by smtp.gmail.com with ESMTPSA id i3sm12022645wrr.19.2021.02.08.10.12.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Feb 2021 10:12:23 -0800 (PST) To: Sean Christopherson Cc: Jing Liu , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, jing2.liu@intel.com References: <20210207154256.52850-1-jing2.liu@linux.intel.com> <20210207154256.52850-4-jing2.liu@linux.intel.com> <77b27707-721a-5c6a-c00d-e1768da55c64@redhat.com> From: Paolo Bonzini Subject: Re: [PATCH RFC 3/7] kvm: x86: XSAVE state and XFD MSRs context switch Message-ID: Date: Mon, 8 Feb 2021 19:12:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/02/21 19:04, Sean Christopherson wrote: >> That said, the case where we saw MSR autoload as faster involved EFER, and >> we decided that it was due to TLB flushes (commit f6577a5fa15d, "x86, kvm, >> vmx: Always use LOAD_IA32_EFER if available", 2014-11-12). Do you know if >> RDMSR/WRMSR is always slower than MSR autoload? > RDMSR/WRMSR may be marginally slower, but only because the autoload stuff avoids > serializing the pipeline after every MSR. That's probably adding up quickly... > The autoload paths are effectively > just wrappers around the WRMSR ucode, plus some extra VM-Enter specific checks, > as ucode needs to perform all the normal fault checks on the index and value. > On the flip side, if the load lists are dynamically constructed, I suspect the > code overhead of walking the lists negates any advantages of the load lists. ... but yeah this is not very encouraging. Context switch time is a problem for XFD. In a VM that uses AMX, most threads in the guest will have nonzero XFD but the vCPU thread itself will have zero XFD. So as soon as one thread in the VM forces the vCPU thread to clear XFD, you pay a price on all vmexits and vmentries. However, running the host with _more_ bits set than necessary in XFD should not be a problem as long as the host doesn't use the AMX instructions. So perhaps Jing can look into keeping XFD=0 for as little time as possible, and XFD=host_XFD|guest_XFD as much as possible. Paolo