From: Avi Kivity <avi@redhat.com>
To: Joerg Roedel <joerg.roedel@amd.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
Alexander Graf <agraf@suse.de>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] KVM: SVM: Optimize nested svm msrpm merging
Date: Fri, 26 Feb 2010 12:28:24 +0200 [thread overview]
Message-ID: <4B87A248.1050300@redhat.com> (raw)
In-Reply-To: <1267118149-15737-3-git-send-email-joerg.roedel@amd.com>
On 02/25/2010 07:15 PM, Joerg Roedel wrote:
> This patch optimizes the way the msrpm of the host and the
> guest are merged. The old code merged the 2 msrpm pages
> completly. This code needed to touch 24kb of memory for that
> operation. The optimized variant this patch introduces
> merges only the parts where the host msrpm may contain zero
> bits. This reduces the amount of memory which is touched to
> 48 bytes.
>
> Signed-off-by: Joerg Roedel<joerg.roedel@amd.com>
> ---
> arch/x86/kvm/svm.c | 67 +++++++++++++++++++++++++++++++++++++++++++++-------
> 1 files changed, 58 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index d8d4e35..d15e0ea 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -92,6 +92,9 @@ struct nested_state {
>
> };
>
> +#define MSRPM_OFFSETS 16
> +static u32 msrpm_offsets[MSRPM_OFFSETS] __read_mostly;
> +
> struct vcpu_svm {
> struct kvm_vcpu vcpu;
> struct vmcb *vmcb;
> @@ -436,6 +439,34 @@ err_1:
>
> }
>
> +static void add_msr_offset(u32 offset)
> +{
> + u32 old;
> + int i;
> +
> +again:
> + for (i = 0; i< MSRPM_OFFSETS; ++i) {
> + old = msrpm_offsets[i];
> +
> + if (old == offset)
> + return;
> +
> + if (old != MSR_INVALID)
> + continue;
> +
> + if (cmpxchg(&msrpm_offsets[i], old, offset) != old)
> + goto again;
> +
> + return;
> + }
> +
> + /*
> + * If this BUG triggers the msrpm_offsets table has an overflow. Just
> + * increase MSRPM_OFFSETS in this case.
> + */
> + BUG();
> +}
>
Why all this atomic cleverness? The possible offsets are all determined
statically. Even if you do them dynamically (makes sense when
considering pmu passthrough), it's per-vcpu and therefore single
threaded (just move msrpm_offsets into vcpu context).
> @@ -1846,20 +1882,33 @@ static int nested_svm_vmexit(struct vcpu_svm *svm)
>
> static bool nested_svm_vmrun_msrpm(struct vcpu_svm *svm)
> {
> - u32 *nested_msrpm;
> - struct page *page;
> + /*
> + * This function merges the msr permission bitmaps of kvm and the
> + * nested vmcb. It is omptimized in that it only merges the parts where
> + * the kvm msr permission bitmap may contain zero bits
> + */
>
A comment that describes the entire function can be moved above the
function, freeing a whole tab stop for contents.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
next prev parent reply other threads:[~2010-02-26 10:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-25 17:15 [PATCH 0/5] Rework of msrpm optimization and additional fixes for nested svm Joerg Roedel
2010-02-25 17:15 ` [PATCH 1/5] KVM: SVM: Move msrpm offset calculation to seperate function Joerg Roedel
2010-02-26 10:20 ` Avi Kivity
2010-02-26 10:25 ` Joerg Roedel
2010-02-25 17:15 ` [PATCH 2/5] KVM: SVM: Optimize nested svm msrpm merging Joerg Roedel
2010-02-26 10:28 ` Avi Kivity [this message]
2010-02-26 12:25 ` Joerg Roedel
2010-02-26 12:28 ` Alexander Graf
2010-02-26 13:04 ` Joerg Roedel
2010-02-26 13:08 ` Alexander Graf
2010-02-26 13:19 ` Joerg Roedel
2010-02-26 13:10 ` Avi Kivity
2010-02-26 13:21 ` Joerg Roedel
2010-02-26 13:26 ` Alexander Graf
2010-02-26 13:30 ` Joerg Roedel
2010-02-26 13:59 ` Avi Kivity
2010-02-26 12:42 ` Avi Kivity
2010-02-25 17:15 ` [PATCH 3/5] KVM: SVM: Use svm_msrpm_offset in nested_svm_exit_handled_msr Joerg Roedel
2010-02-26 10:30 ` Avi Kivity
2010-03-01 13:33 ` Joerg Roedel
2010-02-25 17:15 ` [PATCH 4/5] KVM: SVM: Add correct handling of nested iopm Joerg Roedel
2010-02-26 10:33 ` Avi Kivity
2010-02-25 17:15 ` [PATCH 5/5] KVM: SVM: Ignore lower 12 bit of nested msrpm_pa Joerg Roedel
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=4B87A248.1050300@redhat.com \
--to=avi@redhat.com \
--cc=agraf@suse.de \
--cc=joerg.roedel@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.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.