From: Jan Beulich <jbeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] x86: refine guest_mode()
Date: Fri, 22 May 2020 14:00:22 +0200 [thread overview]
Message-ID: <a31bd761-54eb-56b8-7c60-93202d26e7d0@suse.com> (raw)
In-Reply-To: <20200522104844.GY54375@Air-de-Roger>
On 22.05.2020 12:48, Roger Pau Monné wrote:
> On Fri, May 22, 2020 at 11:52:42AM +0200, Jan Beulich wrote:
>> On 20.05.2020 17:13, Roger Pau Monné wrote:
>>> OK, so I think I'm starting to understand this all. Sorry it's taken
>>> me so long. So it's my understanding that diff != 0 can only happen in
>>> Xen context, or when in an IST that has a different stack (ie: MCE, NMI
>>> or DF according to current.h) and running in PV mode?
>>>
>>> Wouldn't in then be fine to use (r)->cs & 3 to check we are in guest
>>> mode if diff != 0? I see a lot of other places where cs & 3 is already
>>> used to that effect AFAICT (like entry.S).
>>
>> Technically this would be correct afaics, but the idea with all this
>> is (or should I say "looks to be"?) to have the checks be as tight as
>> possible, to make sure we don't mistakenly consider something "guest
>> mode" which really isn't. IOW your suggestion would be fine with me
>> if we could exclude bugs anywhere in the code. But since this isn't
>> realistic, I consider your suggestion to be relaxing things by too
>> much.
>
> OK, so I take that (long time) we might also want to change the cs & 3
> checks from entry.S to check against __HYPERVISOR_CS explicitly?
I didn't think so, no (not the least because of there not being any
guarantee afaik that EFI runtime calls couldn't play with segment
registers; they shouldn't, yes, but there's a lot of other "should"
many don't obey to). Those are guaranteed PV-only code paths. The
main issue here is that ->cs cannot be relied upon when a frame
points at HVM state.
Jan
next prev parent reply other threads:[~2020-05-22 12:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-27 8:03 [PATCH] x86: refine guest_mode() Jan Beulich
2020-04-27 9:59 ` Roger Pau Monné
2020-04-27 14:08 ` Jan Beulich
2020-04-27 16:00 ` Roger Pau Monné
2020-04-27 14:35 ` Andrew Cooper
2020-04-27 15:15 ` Jan Beulich
2020-04-27 20:11 ` Andrew Cooper
2020-04-28 6:30 ` Jan Beulich
2020-05-18 14:51 ` Roger Pau Monné
2020-05-20 8:56 ` Jan Beulich
2020-05-20 15:13 ` Roger Pau Monné
2020-05-22 9:52 ` Jan Beulich
2020-05-22 10:48 ` Roger Pau Monné
2020-05-22 12:00 ` Jan Beulich [this message]
2020-05-26 10:56 ` Roger Pau Monné
2020-05-26 13:55 ` Jan Beulich
2020-05-27 15:17 ` Roger Pau Monné
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=a31bd761-54eb-56b8-7c60-93202d26e7d0@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.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 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).