From: Alexander Graf <agraf@suse.de>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Avi Kivity <avi@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH 2/3] kvm: svm: reset cr0 properly on vcpu reset
Date: Fri, 19 Mar 2010 16:14:44 +0100 [thread overview]
Message-ID: <4BA394E4.3080107@suse.de> (raw)
In-Reply-To: <20100319145112.GE17834@blackpad.lan.raisama.net>
Eduardo Habkost wrote:
> On Wed, Mar 17, 2010 at 10:48:23PM +0100, Alexander Graf wrote:
>
>> On 17.03.2010, at 22:42, Eduardo Habkost wrote:
>>
>>
>>> On Wed, Mar 17, 2010 at 07:17:32PM +0100, Alexander Graf wrote:
>>>
>>>> Eduardo Habkost wrote:
>>>>
>>>>> svm_vcpu_reset() was not properly resetting the contents of the guest-visible
>>>>> cr0 register, causing the following issue:
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=525699
>>>>>
>>>>> Without resetting cr0 properly, the vcpu was running the SIPI bootstrap routine
>>>>> with paging enabled, making the vcpu get a pagefault exception while trying to
>>>>> run it.
>>>>>
>>>>> Instead of setting vmcb->save.cr0 directly, the new code just resets
>>>>> kvm->arch.cr0 and calls kvm_set_cr0(). The bits that were set/cleared on
>>>>> vmcb->save.cr0 (PG, WP, !CD, !NW) will be set properly by svm_set_cr0().
>>>>>
>>>>> kvm_set_cr0() is used instead of calling svm_set_cr0() directly to make sure
>>>>> kvm_mmu_reset_context() is called to reset the mmu to nonpaging mode.
>>>>>
>>>>> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
>>>>>
>>>>>
>>>> Should this go into -stable?
>>>>
>>> I think so. The patch is from October, was -stable branched before that?
>>>
>> If I read the diff log correctly 2.6.32 kvm development was branched
>> off end of July 2009. The important question is if this patch fixes a
>> regression introduced by some speedup magic.
>>
>
> I have just checked git history, and it looks like this is not a
> regression. Before this patch, vcpu->cr0 (the guest-visible cr0 value)
> was never reset on vcpu reset, but only vcpu->svm->vmcb->save.cr0 (the
> actual cr0 value used by the CPU).
>
Good to know. Thanks for looking into this!
Alex
next prev parent reply other threads:[~2010-03-19 15:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-24 4:49 [PATCH 0/3] kvm: fix cr0 initialization on SIPI reset Eduardo Habkost
2009-10-24 4:49 ` [PATCH 1/3] kvm: vmx: use macros instead of hex value on cr0 initialization Eduardo Habkost
2009-10-24 4:49 ` [PATCH 2/3] kvm: svm: reset cr0 properly on vcpu reset Eduardo Habkost
2010-03-17 18:17 ` Alexander Graf
2010-03-17 21:42 ` Eduardo Habkost
2010-03-17 21:48 ` Alexander Graf
2010-03-19 14:51 ` Eduardo Habkost
2010-03-19 15:14 ` Alexander Graf [this message]
2009-10-24 4:50 ` [PATCH 3/3] kvm: svm: init_vmcb(): remove redundant save->cr0 initialization Eduardo Habkost
2009-10-25 9:40 ` [PATCH 0/3] kvm: fix cr0 initialization on SIPI reset 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=4BA394E4.3080107@suse.de \
--to=agraf@suse.de \
--cc=avi@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kvm@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.