From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Juergen Gross <jgross@suse.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
brian.woods@amd.com,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests
Date: Mon, 07 May 2018 02:00:19 -0600 [thread overview]
Message-ID: <5AF0079302000078001C115B@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <c703837d-bb5f-b652-923e-080b7924323a@citrix.com>
>>> On 07.05.18 at 09:30, <andrew.cooper3@citrix.com> wrote:
> On 07/05/2018 08:03, Jan Beulich wrote:
>>>>> On 04.05.18 at 19:28, <andrew.cooper3@citrix.com> wrote:
>>> --- a/xen/arch/x86/pv/emul-priv-op.c
>>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>>> @@ -867,7 +867,9 @@ static int read_msr(unsigned int reg, uint64_t *val,
>>> return X86EMUL_OKAY;
>>>
>>> case MSR_EFER:
>>> - *val = read_efer();
>>> + /* Hide unknown bits, and unconditionally hide SVME from guests. */
>>> + *val = read_efer() & EFER_KNOWN_MASK & ~EFER_SVME;
>>> + /* Hide the 64-bit features from 32-bit guests. */
>>> if ( is_pv_32bit_domain(currd) )
>>> *val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE);
>> Wouldn't it be better then to also move the LMSLE hiding up?
>
> Actually, on second consideration, LMSLE shouldn't be hidden. If LMSLE
> is actually active, then segment descriptors behave differently whether
> the guest knows about it or not.
Actually - the placement shouldn't matter at all: I think it can't be set anyway,
as we would only possibly allow HVM guests to set it, i.e. the EFER value
loaded during #VMEXIT won't ever have the bit set at present. And even the
HVM side code uniformly forces cpu_has_lmsl to false right now.
>> And what about SCE?
>
> Rather more difficult to say, given its cross-vendor behaviour. It
> should probably be clobbered if 32bit && Intel, but 32bit AMD can use
> SYSCALL if it wishes.
Ah, yes, agreed.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-05-07 8:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-04 17:28 [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests Andrew Cooper
2018-05-04 18:45 ` Boris Ostrovsky
2018-05-04 18:48 ` Andrew Cooper
2018-05-07 6:28 ` Juergen Gross
2018-05-07 7:03 ` Jan Beulich
2018-05-07 7:30 ` Andrew Cooper
2018-05-07 8:00 ` Jan Beulich [this message]
2018-05-07 8:10 ` Andrew Cooper
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=5AF0079302000078001C115B@prv1-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=brian.woods@amd.com \
--cc=jgross@suse.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 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.