Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3781946pxj; Mon, 24 May 2021 14:58:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyFr8/+Jt4r3sUmcvhh7VjRpH4gJQG6GaHUhlvF6lYuP+pwoHXfr1GIepFcRpOJkNw163gn X-Received: by 2002:a05:6638:155:: with SMTP id y21mr28216305jao.62.1621893502710; Mon, 24 May 2021 14:58:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621893502; cv=none; d=google.com; s=arc-20160816; b=yOv3oL/FwQeNZ8p5ySxhpoO59Ytae2fE+VyzdAp1WUyqqyvZVlXgGuG+UHQTuvFWEb tarKc5SxbomlcOPack1MoEOsQUBJTGGXLNT6/E/fkYPGn7JJGOrNe5M/MAZzMUIMg4Gt 8zpl2P6bQIzRn4tD5lFONikAEfKRjGLXUBi7g1Zl4SFgqe9aitULpUyvb00BtfkNWGyu bTbcuXNStK5vDohrSG7FmqcLGKO5ONFM+RSJ5Nseic5X0qs1vXXs++KcrMfLwEtC8g1f CSp38nUb9P8fryosrGyzMBb3SzKfquzsXH0P08U+tlELIOxPs6UpTpYJzKypSceki7c2 kxbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=+QOd1KfRYOgHgN+WbksAwHnKrFOkuvhhmy1/CWBQTUM=; b=uie+/Fwvcb+PU6e9/Q/YEKf1am605NYUo7ntCr0m0Ddgq9GEGsgpFTe6VA20l0I6Lw LhJNVKBvjhsVPQP+MFCm8vNnm4VrmE3UreIVlXLjl7ek+/1ua9So9PiuNT0q9Snum4cl zHQvzpMtUBiBXF7ZzoV8DPiMcB/BThF2TUskdEYY/hBCcbNzUIpoQ7TTwkzJvsVVKjyS 7YhJ4QDuFC7KrV2S4BOufQ1ot6W6qV4mMDRLjR6h7MBZ9fnvFpi+x+vyA4sXBllEq0Cn Zb1cxwFB43Ug/kucxocMmhm/RxiKp7slDzJVZmXtF4CzGG1Fvni1OgL9LrD8D6XwA/9/ 7rcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=KhP+msE1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m17si14571996ilg.130.2021.05.24.14.58.09; Mon, 24 May 2021 14:58:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=KhP+msE1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233126AbhEXV7K (ORCPT + 99 others); Mon, 24 May 2021 17:59:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49410 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232911AbhEXV7K (ORCPT ); Mon, 24 May 2021 17:59:10 -0400 Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CF888C061756 for ; Mon, 24 May 2021 14:57:41 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id w127so24590166oig.12 for ; Mon, 24 May 2021 14:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+QOd1KfRYOgHgN+WbksAwHnKrFOkuvhhmy1/CWBQTUM=; b=KhP+msE1sBjTgPeZHuqohUHYU8q1MCHlCmd7BM0DG/QQPq0BVCAhBRoWQAvvPWXC3B dzIdRw0drYiWC6puPbIgYlYpn/RgzymNyAilhIgJHplegheMKxhJbEiyiZoetKiLi/mn ykAJ174khzSSndRTgw6U9AFmHJqWdsxK8JkbtQEwXXdc36S/CA52VJhna92gSZPmwv5R nA3R24Fgi6zEBCNS9WMqIu2SUly94l6303+0NMmlDms+eHSHwj63TutGiZcfguZfweaS orQsAc7kJ9A+u8KBtS9xkbgxtn6aqY6RxeQWOQi93tbqG6KQcnrL00+D/o/+n3fp0k32 0EVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+QOd1KfRYOgHgN+WbksAwHnKrFOkuvhhmy1/CWBQTUM=; b=Qn1kleThdNk6GBZk80WUjFEO+VSjHyhpI7fPncXVwCF89CbENZ39nObw6zuAVAg9Ej u3w8x46OUOFXEOjLhf8JJDWYC7h0gysDnwVmb2zUS1ApEp8HUlmKNvaMKOOc9aOBjYDu dVWijC24C+RyNTLymYvLKvvRLeY4pZLx0APjnIkbpLw7f5k8CJ814ROfXRbhp+Edn0bU 7t7OpkUP/e471fdC5kEGNgOYWdgrUWWgG5t7bGww36WxI0n7tJ+Eau8JxQQNq6nWO8Ps vxwhNpjM4Pvvs8RA89ccIWjhy1PJYrcFrgPayiqb5NOyQaFYA4Z3qPxQOvxF0+C7Udhs cdwg== X-Gm-Message-State: AOAM532YP45/I6pMHFcvzizLNXcohtJDBdgsRJSRrmVi2q/q+QD1hZoc Ky5wGlHHPK/uLZ/dOGAU9FmqbK5zOMt9xa6NswcZ7w== X-Received: by 2002:aca:280a:: with SMTP id 10mr813875oix.13.1621893460868; Mon, 24 May 2021 14:57:40 -0700 (PDT) MIME-Version: 1.0 References: <20210207154256.52850-1-jing2.liu@linux.intel.com> <20210207154256.52850-3-jing2.liu@linux.intel.com> In-Reply-To: From: Jim Mattson Date: Mon, 24 May 2021 14:57:29 -0700 Message-ID: Subject: Re: [PATCH RFC 2/7] kvm: x86: Introduce XFD MSRs as passthrough to guest To: Sean Christopherson Cc: Jing Liu , Paolo Bonzini , kvm list , LKML , jing2.liu@intel.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 24, 2021 at 2:44 PM Sean Christopherson wrote: > > On Sun, Feb 07, 2021, Jing Liu wrote: > > Passthrough both MSRs to let guest access and write without vmexit. > > Why? Except for read-only MSRs, e.g. MSR_CORE_C1_RES, passthrough MSRs are > costly to support because KVM must context switch the MSR (which, by the by, is > completely missing from the patch). > > In other words, if these MSRs are full RW passthrough, guests with XFD enabled > will need to load the guest value on entry, save the guest value on exit, and > load the host value on exit. That's in the neighborhood of a 40% increase in > latency for a single VM-Enter/VM-Exit roundtrip (~1500 cycles => >2000 cycles). > > I'm not saying these can't be passhthrough, but there needs to be strong > justification for letting the guest read/write them directly. If we virtualize XFD, we have to context switch the guest/host values on VM-entry/VM-exit, don't we? If we don't, we're forced to synthesize the #NM on any instruction that would access a disabled state component, and I don't think we have any way of doing that. We could intercept a guest WRMSR to these MSRs, but it sounds like the guest can still implicitly write to IA32_XFD_ERR, if we allow it to have a non-zero IA32_XFD. Perhaps the answer is "don't virtualize XFD."