From: Brian Woods <brian.woods@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Brian Woods <brian.woods@amd.com>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCH v2 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD
Date: Thu, 8 Feb 2018 10:23:27 -0600 [thread overview]
Message-ID: <20180208162326.GA12156@amd.com> (raw)
In-Reply-To: <5A7C2A4B02000078001A64C3@prv-mh.provo.novell.com>
On Thu, Feb 08, 2018 at 02:45:31AM -0700, Jan Beulich wrote:
> I'm afraid I continue to be confused: A function with this name should
> imo, as said earlier, live in nestedsvm.c. However ...
I'll move it to nestedsvm.c then.
> ... this indicates that the function does something even for the
> non-nested case. In particular ...
It makes sure that SVME isn't set when nested isn't enabled.
If SVME is set it does certain checks to enable features if enabled.
Else it makes sure nested features are turned off.
The reason for this is that, with VGIF/VVMLOAD, they can still work even
with SVME not being set. This sets it where they get intercepted to Xen
so that Xen can correctly emulate what should be happening. If SVME
isn't set then nested guest shouldn't be able to do VGIF/VVMLOAD.
> ... this entire else block. Is it necessary to do this in the non-nested
> case? IOW - do these settings ever change there (I would have
> thought that the two *_enable fields checked by the two if()s should
> never be true for nested-disabled guests)? Otherwise, as also said
> before, the caller should call here only when
> nestedhvm_enabled(v->domain), and the function would better
> move.
>
> Jan
It only checks two things (two if statements) in the VMCB per EFER
update. Suppose you add an if to check if it's a nested guest and then
run the nested_features func. You're only saving a total of one if and
going in and out a function but you add a small divergence in the
codepath. If this was a long computer/IO intense function, I'd
completely agree but this is two very simple checks.
I'll change it though, since it'll be easier than going back and forth
about a minor detail.
--
Brian Woods
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-02-08 16:23 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-31 20:35 [PATCH 0/3] Various SVM Cleanups Brian Woods
2018-01-31 20:35 ` [PATCH 1/3] x86/svm: update VGIF support Brian Woods
2018-02-03 16:51 ` Boris Ostrovsky
2018-01-31 20:35 ` [PATCH 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD Brian Woods
2018-02-03 16:55 ` Boris Ostrovsky
2018-02-05 9:09 ` Jan Beulich
2018-02-05 16:47 ` Brian Woods
2018-02-05 17:02 ` Jan Beulich
2018-02-05 15:37 ` Andrew Cooper
2018-02-05 16:39 ` Brian Woods
2018-02-07 21:06 ` [PATCH v2 " Brian Woods
2018-02-07 21:15 ` Brian Woods
[not found] ` <5A7B6A7C0200003403432E6E@prv-mh.provo.novell.com>
2018-02-08 9:45 ` Jan Beulich
2018-02-08 16:23 ` Brian Woods [this message]
[not found] ` <5A7C82880200003F043E54B7@prv-mh.provo.novell.com>
2018-02-13 9:31 ` [PATCH v3 " Jan Beulich
2018-02-13 18:37 ` Woods, Brian
2018-02-14 8:01 ` Jan Beulich
2018-02-08 17:01 ` Brian Woods
2018-02-20 22:27 ` [PATCH v4 " Brian Woods
2018-02-20 22:52 ` Boris Ostrovsky
2018-02-20 22:00 ` [PATCH v2 " Brian Woods
2018-02-20 22:09 ` Boris Ostrovsky
2018-02-20 22:14 ` Brian Woods
2018-01-31 20:35 ` [PATCH 3/3] x86/svm: correct EFER.SVME intercept checks Brian Woods
2018-02-03 17:03 ` Boris Ostrovsky
2018-02-03 17:10 ` Andrew Cooper
2018-02-03 17:15 ` Boris Ostrovsky
2018-02-05 9:18 ` Jan Beulich
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=20180208162326.GA12156@amd.com \
--to=brian.woods@amd.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).