From: Avi Kivity <avi@redhat.com>
To: oritw@il.ibm.com
Cc: kvm@vger.kernel.org, benami@il.ibm.com, abelg@il.ibm.com,
muli@il.ibm.com, aliguori@us.ibm.com, mdday@us.ibm.com
Subject: Re: [PATCH 5/7] Nested VMX patch 5 Simplify fpu handling
Date: Thu, 17 Dec 2009 11:10:38 +0200 [thread overview]
Message-ID: <4B29F58E.4090407@redhat.com> (raw)
In-Reply-To: <1260470309-7166-6-git-send-email-oritw@il.ibm.com>
On 12/10/2009 08:38 PM, oritw@il.ibm.com wrote:
> From: Orit Wasserman<oritw@il.ibm.com>
>
>
What exactly is the simplification? Is it intended to have a functional
change?
> ---
> arch/x86/kvm/vmx.c | 27 +++++++++++++++++----------
> 1 files changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 8745d44..de1f596 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -1244,8 +1244,6 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
> u32 eb;
>
> eb = (1u<< PF_VECTOR) | (1u<< UD_VECTOR) | (1u<< MC_VECTOR);
> - if (!vcpu->fpu_active)
> - eb |= 1u<< NM_VECTOR;
> /*
> * Unconditionally intercept #DB so we can maintain dr6 without
> * reading it every exit.
> @@ -1463,10 +1461,6 @@ static void vmx_fpu_activate(struct kvm_vcpu *vcpu)
> if (vcpu->fpu_active)
> return;
> vcpu->fpu_active = 1;
> - vmcs_clear_bits(GUEST_CR0, X86_CR0_TS);
> - if (vcpu->arch.cr0& X86_CR0_TS)
> - vmcs_set_bits(GUEST_CR0, X86_CR0_TS);
> - update_exception_bitmap(vcpu);
> }
>
> static void vmx_fpu_deactivate(struct kvm_vcpu *vcpu)
> @@ -1474,8 +1468,6 @@ static void vmx_fpu_deactivate(struct kvm_vcpu *vcpu)
> if (!vcpu->fpu_active)
> return;
> vcpu->fpu_active = 0;
> - vmcs_set_bits(GUEST_CR0, X86_CR0_TS);
> - update_exception_bitmap(vcpu);
> }
>
> static unsigned long vmx_get_rflags(struct kvm_vcpu *vcpu)
> @@ -2715,8 +2707,10 @@ static void vmx_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
>
> vmx_flush_tlb(vcpu);
> vmcs_writel(GUEST_CR3, guest_cr3);
> - if (vcpu->arch.cr0& X86_CR0_PE)
> - vmx_fpu_deactivate(vcpu);
> + if (vcpu->arch.cr0& X86_CR0_PE) {
> + if (guest_cr3 != vmcs_readl(GUEST_CR3))
> + vmx_fpu_deactivate(vcpu);
> + }
>
Why the added cr3 check? It may make sense, but it isn't a simplification.
> static void vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
> @@ -5208,6 +5202,19 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
> if (vcpu->arch.switch_db_regs)
> get_debugreg(vcpu->arch.dr6, 6);
>
> + if (vcpu->fpu_active) {
> + if (vmcs_readl(CR0_READ_SHADOW)& X86_CR0_TS)
> + vmcs_set_bits(GUEST_CR0, X86_CR0_TS);
> + else
> + vmcs_clear_bits(GUEST_CR0, X86_CR0_TS);
> + vmcs_write32(EXCEPTION_BITMAP,
> + vmcs_read32(EXCEPTION_BITMAP)& ~(1u<< NM_VECTOR));
> + } else {
> + vmcs_set_bits(GUEST_CR0, X86_CR0_TS);
> + vmcs_write32(EXCEPTION_BITMAP,
> + vmcs_read32(EXCEPTION_BITMAP) | (1u<< NM_VECTOR));
> + }
>
This is executed unconditionally, so the vmreads/vmwrites take place
every time. Need to cache the previous fpu_active state and only take
action if it changed.
Since this is a large piece of code, move it to a function.
Please post this as the first patch (or better, separately), so I can
apply it independently of the rest.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2009-12-17 9:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-10 18:38 Nested VMX support v4 oritw
2009-12-10 18:38 ` [PATCH 1/7] Nested VMX patch 1 implements vmon and vmoff oritw
2009-12-10 18:38 ` [PATCH 2/7] Nested VMX patch 2 implements vmclear oritw
2009-12-10 18:38 ` [PATCH 3/7] Nested VMX patch 3 implements vmptrld and vmptrst oritw
2009-12-10 18:38 ` [PATCH 4/7] Nested VMX patch 4 implements vmread and vmwrite oritw
2009-12-10 18:38 ` [PATCH 5/7] Nested VMX patch 5 Simplify fpu handling oritw
2009-12-10 18:38 ` [PATCH 6/7] Nested VMX patch 6 implements vmlaunch and vmresume oritw
2009-12-10 18:38 ` [PATCH 7/7] Nested VMX patch 7 handling of nested guest exits oritw
2009-12-17 13:46 ` Avi Kivity
2009-12-17 10:10 ` [PATCH 6/7] Nested VMX patch 6 implements vmlaunch and vmresume Avi Kivity
2009-12-17 9:10 ` Avi Kivity [this message]
2009-12-16 14:44 ` [PATCH 4/7] Nested VMX patch 4 implements vmread and vmwrite Avi Kivity
2009-12-16 14:32 ` [PATCH 3/7] Nested VMX patch 3 implements vmptrld and vmptrst Avi Kivity
2009-12-16 13:59 ` [PATCH 2/7] Nested VMX patch 2 implements vmclear Avi Kivity
2009-12-28 14:57 ` Gleb Natapov
2009-12-16 13:34 ` [PATCH 1/7] Nested VMX patch 1 implements vmon and vmoff Avi Kivity
2009-12-20 14:20 ` Gleb Natapov
2009-12-20 14:23 ` Avi Kivity
2009-12-20 14:25 ` Gleb Natapov
2009-12-20 17:08 ` Andi Kleen
2009-12-20 19:04 ` Avi Kivity
2009-12-21 15:52 ` Muli Ben-Yehuda
2009-12-21 16:00 ` Avi Kivity
2009-12-17 13:49 ` Nested VMX support v4 Avi Kivity
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=4B29F58E.4090407@redhat.com \
--to=avi@redhat.com \
--cc=abelg@il.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=benami@il.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=mdday@us.ibm.com \
--cc=muli@il.ibm.com \
--cc=oritw@il.ibm.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.