From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: WeiLiu <wl@xen.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
xen-devel <xen-devel@lists.xenproject.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Brian Woods <brian.woods@amd.com>,
Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86/svm: Fix svm_vmcb_dump() when used in current context
Date: Mon, 17 Jun 2019 14:59:19 +0100 [thread overview]
Message-ID: <905e57ed-4f26-f446-e04e-9f680bdedbb7@citrix.com> (raw)
In-Reply-To: <5D079BB50200007800238D2B@prv1-mh.provo.novell.com>
On 17/06/2019 14:55, Jan Beulich wrote:
>>>> On 17.06.19 at 14:54, <andrew.cooper3@citrix.com> wrote:
>> VMExit doesn't switch all state. The FS/GS/TS/LDTR/GSBASE segment
>> information, and SYSCALL/SYSENTER MSRs may still be cached in hardware, rather
>> than up-to-date in the VMCB.
>>
>> Export svm_sync_vmcb() via svmdebug.h so svm_vmcb_dump() can use it, and bring
>> the VMCB into sync in current context.
>>
>> As a minor optimisation, switch svm_sync_vmcb() to use svm_vm{load,save}_pa(),
>> as svm->vmcb_pa is always in correct, and this avoids a redundant __pa()
> Is the "in" here a leftover from some earlier, different wording?
Yes. It can be dropped.
>
>> translation behind the scenes.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>
> Only as a remark: This removes the last use of svm_vmload(), but
> perhaps it and svm_vmsave() would better be dropped together,
> once the one remaining use of the latter has also disappeared
> (assuming that's doable).
I noticed and tried to do just that, but removing the final svm_vmsave()
isn't trivial. It is confined to the nested virt code, but I think it
is calling virt_to_maddr() on a domheap mapping, which needs adjusting
not to explode on a system with more than 5T of RAM.
Its in my todo list, but I don't have time to address that right now.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-06-17 13:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 12:54 [Xen-devel] [PATCH] x86/svm: Fix svm_vmcb_dump() when used in current context Andrew Cooper
2019-06-17 13:55 ` Jan Beulich
2019-06-17 13:59 ` Andrew Cooper [this message]
2019-06-19 16:23 ` Woods, Brian
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=905e57ed-4f26-f446-e04e-9f680bdedbb7@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=brian.woods@amd.com \
--cc=roger.pau@citrix.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=wl@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.