From: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
chegger@amazon.de, tim@xen.org
Subject: Re: [PATCH 1/1 V5] x86/AMD: Fix nested svm crash due to assertion in __virt_to_maddr
Date: Wed, 7 Aug 2013 17:18:13 -0500 [thread overview]
Message-ID: <5202C7A5.4070304@amd.com> (raw)
In-Reply-To: <520264F102000078000E9EFA@nat28.tlf.novell.com>
On 8/7/2013 8:17 AM, Jan Beulich wrote:
>>>> On 05.08.13 at 10:31, <suravee.suthikulpanit@amd.com> wrote:
>> From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>>
>> Fix assertion in __virt_to_maddr when starting nested SVM guest
>> in debug mode. Investigation has shown that svm_vmsave/svm_vmload
>> make use of __pa() with invalid address.
>>
>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> Tim - have all your earlier comments been addressed in this version?
>
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1779,15 +1779,15 @@ static void
>> svm_vmexit_do_vmrun(struct cpu_user_regs *regs,
>> struct vcpu *v, uint64_t vmcbaddr)
>> {
>> - if (!nestedhvm_enabled(v->domain)) {
>> + if ( !nestedhvm_enabled(v->domain) || !hvm_svm_enabled(v) ) {
> Suravee, why is this change needed (here and further down)?
> Can we really get here when hvm_svm_enabled(v) returns false?
> I don't recall this having been there in earlier versions.
Basically, I double checked the logic for all the svm_vmexit_do_vmxxx to make sure
that the proper exception has been raised. We had a discussion whether it should
returned #GP or #UD. In this case, if the L1 vcpu does not have SVME
bit in the EFER set, it should return #UD. Otherewise, it should return #GP.
Here the hvm_svm_enabled(v) is return true when L1 guest enabled SVM in EFER.
#define hvm_svm_enabled(v) (!!((v)->arch.hvm_vcpu.guest_efer & EFER_SVME))
So, I decided to add the check here as well. Unless you think it is not necessary.
> Also, if the change _is_ needed, just like done further down you
> should have taken the opportunity and fix the placement of the
> closing brace (also again later in this function).
Will take care of that if needed.
>
>> +static struct page_info *
>> +nsvm_get_nvmcb_page(struct vcpu *v, uint64_t vmcbaddr)
>> +{
>> + p2m_type_t p2mt;
>> + struct page_info *page;
>> + struct nestedvcpu *nv = &vcpu_nestedhvm(v);
>> +
>> + if (!nestedsvm_vmcb_map(v, vmcbaddr))
> Coding style.
OK
>
>> + return NULL;
> Hard tab.
>
> Jan
OK
Thanks,
Suravee
next prev parent reply other threads:[~2013-08-07 22:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 8:31 [PATCH 1/1 V5] x86/AMD: Fix nested svm crash due to assertion in __virt_to_maddr suravee.suthikulpanit
2013-08-07 13:17 ` Jan Beulich
2013-08-07 22:18 ` Suravee Suthikulanit [this message]
2013-08-08 6:47 ` Jan Beulich
2013-08-08 15:55 ` Suravee Suthikulanit
2013-08-12 8:57 ` Egger, Christoph
2013-08-12 9:01 ` Jan Beulich
2013-08-12 11:13 ` Egger, Christoph
2013-08-12 13:18 ` Jan Beulich
2013-08-12 14:04 ` Suravee Suthikulpanit
2013-08-12 14:26 ` Jan Beulich
2013-08-12 14:40 ` Egger, Christoph
2013-08-12 15:26 ` Jan Beulich
2013-08-08 9:38 ` Tim Deegan
2013-08-08 16:42 ` Suravee Suthikulanit
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=5202C7A5.4070304@amd.com \
--to=suravee.suthikulpanit@amd.com \
--cc=JBeulich@suse.com \
--cc=chegger@amazon.de \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.org \
/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.