From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: Julien Grall <julien@xen.org>,
Stefano Stabellini <stefanos@xilinx.com>,
Jan Beulich <jbeulich@suse.com>,
George Dunlap <George.Dunlap@citrix.com>
Subject: Runstate hypercall and Linux KPTI issues
Date: Thu, 10 Sep 2020 13:46:34 +0000 [thread overview]
Message-ID: <1844689F-814F-48AE-8179-95B0EE4E734C@arm.com> (raw)
Hi,
Following my patch[1] to map the guest runstate in Xen during the hypercall directly
instead of doing the conversion from virtual to physical when updating the runstate
content during a context switch a global discussion started[2][3].
To resume the discussion the problem is the following: A guest registers a memory
area for xen to put on and maintain the runstate information. This is done currently
using a guest virtual address which is converted by Xen during context switches.
When KPTI is used and a context switch occurs while linux is running in user space
the area is not mapped and the information is not updated. This results in invalid
runstate information but also in some annoying warning coming up in Xen console
on arm.
After the discussion by mail and the last community call it was proposed to change
the way to go and instead of trying to fix the problem in the existing hypercall, to
introduce a new hypercall taking as parameter a guest physical address for the
runstate area instead of a virtual address in the current hypercall.
This means:
- add a new hypercall to Xen
- add support for this new hypercall in Linux and use it if Xen supports it
- keep existing hypercall with its limitation (for older guests)
- keep support for both behaviour during the context switch
Some open questions:
- should we allow to register an area using both hypercalls or should it be exclusive ?
- should we backport the support for this hypercall in older kernel releases ?
- other ?
Please tell me if you agree or not before I start to plan how this can be implemented :-)
Regards
Bertrand
[1] https://lists.xenproject.org/archives/html/xen-devel/2020-07/msg01541.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2020-07/msg01461.html
[3] https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00810.html
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
next reply other threads:[~2020-09-10 13:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-10 13:46 Bertrand Marquis [this message]
2020-09-10 13:56 ` Runstate hypercall and Linux KPTI issues Jan Beulich
2020-09-10 14:00 ` Bertrand Marquis
2020-09-10 14:04 ` Bertrand Marquis
2020-09-10 14:08 ` Jan Beulich
2020-09-11 0:33 ` Stefano Stabellini
2020-09-24 17:25 ` Bertrand Marquis
2020-09-24 17:28 ` Bertrand Marquis
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=1844689F-814F-48AE-8179-95B0EE4E734C@arm.com \
--to=bertrand.marquis@arm.com \
--cc=George.Dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=stefanos@xilinx.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).