From: Ian Jackson <iwj@xenproject.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"Tim Deegan" <tim@xen.org>,
"George Dunlap" <george.dunlap@citrix.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH][4.15] x86/shadow: suppress "fast fault path" optimization without reserved bits
Date: Thu, 25 Feb 2021 13:17:15 +0000 [thread overview]
Message-ID: <24631.41819.456811.665249@mariner.uk.xensource.com> (raw)
In-Reply-To: <aefe5617-9f10-23a4-ee27-6ea66b62cdbe@suse.com>
Jan Beulich writes ("[PATCH][4.15] x86/shadow: suppress "fast fault path" optimization without reserved bits"):
> When none of the physical address bits in PTEs are reserved, we can't
> create any 4k (leaf) PTEs which would trigger reserved bit faults. Hence
> the present SHOPT_FAST_FAULT_PATH machinery needs to be suppressed in
> this case, which is most easily achieved by never creating any magic
> entries.
>
> To compensate a little, eliminate sh_write_p2m_entry_post()'s impact on
> such hardware.
>
> While at it, also avoid using an MMIO magic entry when that would
> truncate the incoming GFN.
Judging by the description I'm not sure whether this is a bugfix, or
a change to make it possible to run Xen on hardware where currently it
doesn't work at all.
I assume "none of the physical address bits in PTEs are reserved" is
a property of certain hardware, but it wasn't clear to me (i) whether
such platforms currently exists (ii) what the existing Xen code would
do in this case.
Can you enlighten me ?
Thanks,
Ian.
next prev parent reply other threads:[~2021-02-25 13:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-25 13:03 [PATCH][4.15] x86/shadow: suppress "fast fault path" optimization without reserved bits Jan Beulich
2021-02-25 13:11 ` Jan Beulich
2021-02-25 13:20 ` Ian Jackson
2021-02-25 13:25 ` Jan Beulich
2021-02-25 13:17 ` Ian Jackson [this message]
2021-02-25 13:30 ` Jan Beulich
2021-02-26 17:07 ` Tim Deegan
2021-03-01 8:10 ` Jan Beulich
2021-03-01 17:30 ` Ian Jackson
2021-03-01 17:34 ` Andrew Cooper
2021-03-01 17:43 ` Ian Jackson
2021-03-02 10:22 ` Jan Beulich
2021-03-02 12:32 ` Ian Jackson
2021-03-02 13:17 ` Jan Beulich
2021-03-02 10:12 ` 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=24631.41819.456811.665249@mariner.uk.xensource.com \
--to=iwj@xenproject.org \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=tim@xen.org \
--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).