From: Jim Mattson <jmattson@google.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"kvm list" <kvm@vger.kernel.org>,
"Liran Alon" <liran.alon@oracle.com>
Subject: Re: [PATCH 1/7] KVM: nVMX: Intercept VMWRITEs to read-only shadow VMCS fields
Date: Thu, 13 Jun 2019 10:02:42 -0700 [thread overview]
Message-ID: <CALMp9eRb8GC1NH9agiWWwkY5ac4CKxZqzobzmLiV5FiscV_B+A@mail.gmail.com> (raw)
In-Reply-To: <20190507153629.3681-2-sean.j.christopherson@intel.com>
On Tue, May 7, 2019 at 8:36 AM Sean Christopherson
<sean.j.christopherson@intel.com> wrote:
> Not intercepting fields tagged read-only also allows for additional
> optimizations, e.g. marking GUEST_{CS,SS}_AR_BYTES as SHADOW_FIELD_RO
> since those fields are rarely written by a VMMs, but read frequently.
Do you have data to support this, or is this just a gut feeling? The
last time I looked at Virtual Box (which was admittedly a long time
ago), it liked to read and write just about every VMCS guest-state
field it could find on every VM-exit.
The decision of which fields to shadow is really something that should
be done dynamically, depending on the behavior of the guest hypervisor
(which may vary depending on the L2 guest it's running!) Making the
decision statically is bound to result in a poor outcome for some
scenarios.
When I measured this several years ago, taking one VM-exit for a
VMREAD or VMWRITE was more expensive than needlessly shadowing it
~35-40 times.
next prev parent reply other threads:[~2019-06-13 17:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-07 15:36 [PATCH 0/7] KVM: nVMX: Optimize VMCS data copying Sean Christopherson
2019-05-07 15:36 ` [PATCH 1/7] KVM: nVMX: Intercept VMWRITEs to read-only shadow VMCS fields Sean Christopherson
2019-06-06 13:26 ` Paolo Bonzini
2019-06-13 17:02 ` Jim Mattson [this message]
2019-06-13 17:18 ` Paolo Bonzini
2019-06-13 17:36 ` Jim Mattson
2019-06-13 17:59 ` Paolo Bonzini
2019-05-07 15:36 ` [PATCH 2/7] KVM: nVMX: Intercept VMWRITEs to GUEST_{CS,SS}_AR_BYTES Sean Christopherson
2019-06-06 13:31 ` Paolo Bonzini
2019-05-07 15:36 ` [PATCH 3/7] KVM: nVMX: Track vmcs12 offsets for shadowed VMCS fields Sean Christopherson
2019-05-07 15:36 ` [PATCH 4/7] KVM: nVMX: Lift sync_vmcs12() out of prepare_vmcs12() Sean Christopherson
2019-05-07 15:36 ` [PATCH 5/7] KVM: nVMX: Use descriptive names for VMCS sync functions and flags Sean Christopherson
2019-05-07 15:36 ` [PATCH 6/7] KVM: nVMX: Add helpers to identify shadowed VMCS fields Sean Christopherson
2019-05-07 15:36 ` [PATCH 7/7] KVM: nVMX: Sync rarely accessed guest fields only when needed Sean Christopherson
2019-06-06 15:29 ` Paolo Bonzini
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=CALMp9eRb8GC1NH9agiWWwkY5ac4CKxZqzobzmLiV5FiscV_B+A@mail.gmail.com \
--to=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=liran.alon@oracle.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=sean.j.christopherson@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).