All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Mattson <jmattson@google.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Jing Liu <jing2.liu@linux.intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm list <kvm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	jing2.liu@intel.com
Subject: Re: [PATCH RFC 2/7] kvm: x86: Introduce XFD MSRs as passthrough to guest
Date: Mon, 24 May 2021 14:57:29 -0700	[thread overview]
Message-ID: <CALMp9eTjgMDG2rKqKkb3WAsQXqfss1QEHWo5CJZHdd8r_XHRqg@mail.gmail.com> (raw)
In-Reply-To: <YKwd5OTXr97Fxfok@google.com>

On Mon, May 24, 2021 at 2:44 PM Sean Christopherson <seanjc@google.com> 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."

  reply	other threads:[~2021-05-24 21:57 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-07 15:42 [PATCH RFC 0/7] Introduce support for guest AMX feature Jing Liu
2021-02-07 15:42 ` [PATCH RFC 1/7] kvm: x86: Expose XFD CPUID to guest Jing Liu
2021-05-24 21:34   ` Sean Christopherson
2021-06-07  3:27     ` Liu, Jing2
2021-02-07 15:42 ` [PATCH RFC 2/7] kvm: x86: Introduce XFD MSRs as passthrough " Jing Liu
2021-05-24 21:43   ` Sean Christopherson
2021-05-24 21:57     ` Jim Mattson [this message]
2021-06-02  3:12     ` Liu, Jing2
2021-06-23 17:50     ` Dave Hansen
2021-06-28  2:00       ` Liu, Jing2
2021-06-29 17:58         ` Dave Hansen
2021-07-06  7:33           ` Liu, Jing2
2021-02-07 15:42 ` [PATCH RFC 3/7] kvm: x86: XSAVE state and XFD MSRs context switch Jing Liu
2021-02-07 11:49   ` Borislav Petkov
2021-02-08  3:35     ` Liu, Jing2
2021-02-08 10:25   ` Paolo Bonzini
2021-02-08 17:31     ` Sean Christopherson
2021-02-08 17:45       ` Paolo Bonzini
2021-02-08 18:04         ` Sean Christopherson
2021-02-08 18:12           ` Paolo Bonzini
2021-02-08 18:55             ` Konrad Rzeszutek Wilk
2021-02-22  8:51               ` Liu, Jing2
2021-02-22  8:36             ` Liu, Jing2
2021-02-07 15:42 ` [PATCH RFC 4/7] kvm: x86: Add new ioctls for XSAVE extension Jing Liu
2021-05-24 21:50   ` Sean Christopherson
2021-05-26  6:09     ` Liu, Jing2
2021-05-26 14:43       ` Sean Christopherson
2021-06-01 10:24         ` Liu, Jing2
2021-06-07  5:23           ` Liu, Jing2
2021-05-24 22:06   ` Jim Mattson
2021-05-26  6:11     ` Liu, Jing2
2021-02-07 15:42 ` [PATCH RFC 5/7] kvm: x86: Revise CPUID.D.1.EBX for alignment rule Jing Liu
2021-05-24 21:28   ` Sean Christopherson
2021-06-03  4:45     ` Liu, Jing2
2021-02-07 15:42 ` [PATCH RFC 6/7] kvm: x86: Add AMX_TILE, AMX_INT8 and AMX_BF16 support Jing Liu
2021-02-07 15:42 ` [PATCH RFC 7/7] kvm: x86: AMX XCR0 support for guest Jing Liu
2021-05-24 21:53   ` Sean Christopherson
2021-05-26  7:54     ` Liu, Jing2
2021-05-26 14:54       ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALMp9eTjgMDG2rKqKkb3WAsQXqfss1QEHWo5CJZHdd8r_XHRqg@mail.gmail.com \
    --to=jmattson@google.com \
    --cc=jing2.liu@intel.com \
    --cc=jing2.liu@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.