From: "Teddy Astie" <teddy.astie@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" <teddy.astie@vates.tech>,
"Jan Beulich" <jbeulich@suse.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Michal Orzel" <michal.orzel@amd.com>,
"Julien Grall" <julien@xen.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Juergen Gross" <jgross@suse.com>,
"Dario Faggioli" <dfaggioli@suse.com>,
"George Dunlap" <gwd@xenproject.org>,
"Daniel P. Smith" <dpsmith@apertussolutions.com>
Subject: [RFC PATCH 0/9] x86/hvm: New Xen HVM ABI proposal ("HVMv2" part 1)
Date: Thu, 21 Aug 2025 15:25:49 +0000 [thread overview]
Message-ID: <cover.1755785258.git.teddy.astie@vates.tech> (raw)
Hello, this series introduce a new hypercall ABI proposal (x86 only for now).
The current Xen ABI has some shortcommings :
First, the hypercall parameters are usually pointers that point to a structure
in guest memory, this pointer is usually a virtual address.
It causes various issues as :
- you need to define a format for these structures which is currently C
structures, but it complicates support with non LP64 platforms (e.g Windows)
or other programming languages (e.g Rust, where solutions are hard to come with)
- the translation from virtual address to machine physical address is very expensive
as you need to translate the GVA to GPA, and then GPA to HPA each time you want to
access a virtual address
- such virtual addresses are not readable under confidential computing guests which
makes such new ABI required.
Another issue is that all possible Xen hypercalls are exposed through this
single interface, it makes hardening the hypervisor more complicated as you
need to permission check on a per-hypercall basis (e.g through XSM) instead
of having a minimal strict safe-for-guest-use set of operations.
The current ABI allows the guest to modify its physmap; this is notably used for
mapping the shared info, grant table and ballooning. While we could make that work
for confidential guests. It comes with its own set of problems, and in order to
simplify the memory management, this series come with a proposal for mapping these
specific pages in advance and telling the guest the location. That helps reducing
the scope of this new ABI. Ballooning implementation hasn't been fully considered yet.
This series propose a new hypercall interface designed for use by guests kernels
with high performance (low hypercall overhead) and confidential computing environments
(notably AMD SEV) compatibility in mind. It currently only supports x86 long mode
(64-bits) due to specific register requirements.
It doesn't aim to entirely replace the current ABI, but to propose a alternative
one that could be used by guests as a fast-path ABI or for confidential computing
guests.
This new ABI maps into current many operations (with some limitations), a tool is
provided to generate C stubs using the yaml specification.
These C stubs reuse the existing hypercall structures to ease adding support
for this ABI in guests.
You can find some example generated headers in Linux SEV WIP branch [1].
[1] https://github.com/xcp-ng/linux/tree/xen-sev-6.14/include/xen/interface/fastabi
Teddy Astie (9):
x86/hvm: Use direct structures instead of guest handles
common: Isolate XENVER_get_features into a separate function
common/grant_table: Use direct structures instead of guest handles
hvm: Introduce "fixed memory layout" feature
docs/x86: Introduce FastABI
sched: Extract do_poll main logic into vcpu_poll
x86/hvm: Introduce FastABI implementation
hvm: Introduce XEN_HVM_MEMMAP_TYPE_HOTPLUG_ZONE
tools: Introduce abi-tool
docs/guest-guide/x86/fastabi.pandoc | 50 +++++
.../x86/fixed-memory-layout.pandoc | 24 ++
docs/guest-guide/x86/index.rst | 2 +
tools/include/xen-tools/common-macros.h | 4 +
tools/libs/guest/xg_dom_x86.c | 84 +++++++
tools/libs/light/libxl_create.c | 1 +
tools/libs/light/libxl_types.idl | 1 +
tools/libs/light/libxl_x86.c | 71 ++++++
tools/xl/xl_parse.c | 1 +
xen/abi/event_channel.yml | 130 +++++++++++
xen/abi/grant_table.yml | 46 ++++
xen/abi/hvm.yml | 50 +++++
xen/abi/memory.yml | 11 +
xen/abi/sched.yml | 48 ++++
xen/abi/vcpu.yml | 139 ++++++++++++
xen/abi/version.yml | 15 ++
xen/arch/x86/cpuid.c | 3 +
xen/arch/x86/domain.c | 71 ++++++
xen/arch/x86/hvm/hvm.c | 205 +++++++++++++-----
xen/arch/x86/hvm/hypercall.c | 22 ++
xen/arch/x86/include/asm/fastabi.h | 17 ++
xen/common/Kconfig | 6 +
xen/common/Makefile | 1 +
xen/common/domain.c | 179 +++++++++++++++
xen/common/event_channel.c | 199 +++++++++++++++++
xen/common/fastabi.c | 49 +++++
xen/common/grant_table.c | 112 +++++++---
xen/common/kernel.c | 117 ++++++----
xen/common/memory.c | 110 ++++++++++
xen/common/sched/core.c | 149 +++++++++++--
xen/include/public/arch-x86/cpuid.h | 4 +
xen/include/public/arch-x86/hvm/start_info.h | 8 +
xen/include/public/event_channel.h | 7 +
xen/include/public/fastabi.h | 20 ++
xen/include/xen/fastabi.h | 21 ++
xen/tools/abi-tool/.gitignore | 1 +
xen/tools/abi-tool/Cargo.lock | 145 +++++++++++++
xen/tools/abi-tool/Cargo.toml | 11 +
xen/tools/abi-tool/src/abi.rs | 23 ++
xen/tools/abi-tool/src/c_lang.rs | 173 +++++++++++++++
xen/tools/abi-tool/src/main.rs | 17 ++
xen/tools/abi-tool/src/spec.rs | 61 ++++++
42 files changed, 2265 insertions(+), 143 deletions(-)
create mode 100644 docs/guest-guide/x86/fastabi.pandoc
create mode 100644 docs/guest-guide/x86/fixed-memory-layout.pandoc
create mode 100644 xen/abi/event_channel.yml
create mode 100644 xen/abi/grant_table.yml
create mode 100644 xen/abi/hvm.yml
create mode 100644 xen/abi/memory.yml
create mode 100644 xen/abi/sched.yml
create mode 100644 xen/abi/vcpu.yml
create mode 100644 xen/abi/version.yml
create mode 100644 xen/arch/x86/include/asm/fastabi.h
create mode 100644 xen/common/fastabi.c
create mode 100644 xen/include/public/fastabi.h
create mode 100644 xen/include/xen/fastabi.h
create mode 100644 xen/tools/abi-tool/.gitignore
create mode 100644 xen/tools/abi-tool/Cargo.lock
create mode 100644 xen/tools/abi-tool/Cargo.toml
create mode 100644 xen/tools/abi-tool/src/abi.rs
create mode 100644 xen/tools/abi-tool/src/c_lang.rs
create mode 100644 xen/tools/abi-tool/src/main.rs
create mode 100644 xen/tools/abi-tool/src/spec.rs
--
2.50.1
Teddy Astie | Vates XCP-ng Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
next reply other threads:[~2025-08-21 15:26 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 15:25 Teddy Astie [this message]
2025-08-21 15:25 ` [RFC PATCH 1/9] x86/hvm: Use direct structures instead of guest handles Teddy Astie
2025-08-28 12:16 ` Jan Beulich
2025-08-29 13:10 ` Teddy Astie
2025-08-21 15:25 ` [RFC PATCH 2/9] common: Isolate XENVER_get_features into a separate function Teddy Astie
2025-08-28 12:18 ` Jan Beulich
2025-08-21 15:25 ` [RFC PATCH 3/9] common/grant_table: Use direct structures instead of guest handles Teddy Astie
2025-08-28 12:21 ` Jan Beulich
2025-08-21 15:25 ` [RFC PATCH 5/9] docs/x86: Introduce FastABI Teddy Astie
2025-08-28 12:32 ` Jan Beulich
2025-08-29 13:59 ` Teddy Astie
2025-09-01 15:52 ` Jan Beulich
2025-08-21 15:25 ` [RFC PATCH 4/9] hvm: Introduce "fixed memory layout" feature Teddy Astie
2025-08-28 12:30 ` Jan Beulich
2025-08-29 13:32 ` Teddy Astie
2025-09-01 15:48 ` Jan Beulich
2025-10-20 13:26 ` Teddy Astie
2025-10-20 13:43 ` Jan Beulich
2025-08-21 15:25 ` [RFC PATCH 6/9] sched: Extract do_poll main logic into vcpu_poll Teddy Astie
2025-08-28 12:36 ` Jan Beulich
2025-08-21 15:25 ` [RFC PATCH 7/9] x86/hvm: Introduce FastABI implementation Teddy Astie
2025-08-21 15:25 ` [RFC PATCH 8/9] hvm: Introduce XEN_HVM_MEMMAP_TYPE_HOTPLUG_ZONE Teddy Astie
2025-08-28 12:38 ` Jan Beulich
2025-08-29 13:48 ` Teddy Astie
2025-08-21 15:25 ` [RFC PATCH 9/9] tools: Introduce abi-tool Teddy Astie
2025-08-24 22:36 ` Demi Marie Obenour
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=cover.1755785258.git.teddy.astie@vates.tech \
--to=teddy.astie@vates.tech \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=dfaggioli@suse.com \
--cc=dpsmith@apertussolutions.com \
--cc=gwd@xenproject.org \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.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 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.