All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Teddy Astie" <teddy.astie@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: "Teddy Astie" <teddy.astie@vates.tech>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Anthony PERARD" <anthony.perard@vates.tech>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Julien Grall" <julien@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Juergen Gross" <jgross@suse.com>
Subject: [RFC PATCH 0/4] Physical address hypercall ABI ("HVMv2")
Date: Fri, 18 Apr 2025 14:18:39 +0000	[thread overview]
Message-ID: <cover.1744981654.git.teddy.astie@vates.tech> (raw)

In current HVM mode, when a hypercall references a structure in guest memory,
it is passed to the hypervisor as its "linear address" (e.g virtual address for
the x86 long mode).
One of the caveats is that this linear address (GVA) is generally not directly
usable by the Xen and needs to be translated from GVA to GPA then HPA. This
implies a complex and potentially expensive lookup of the pagetables inside the
guest. This can be significant, especially if the P2M cannot use efficiently
superpages (or with e.g XSA-304).

This proposal introduce a new mode where all addresses used for hypercalls are
GPADDR instead of GVADDR, therefore, looking up the HPA related to this GPA
only needs a P2M lookup and not looking through the inside-guest pagetables.

This mode is opt-in and must be enabled explicitely by the toolstack.

This is also mandatory for confidential-computing guests (e.g SEV) where the
guest pagetable are not visible to the hypervisor.

In a synthetic xtf-based hypercall benchmark (VCPUOP_get_runstate_info loop),
it gives broadly a 30% overhead reduction when tested on a AMD EPYC 9124.

This serie only implement support for x86 yet this ABI is also meaningful for
other architectures as well.
A separate patch for adding support in Linux is planned.

Teddy Astie (4):
  xen: Introduce physaddr_abi CDF flag
  x86/hvm: Consider phyaddr_abi when copying from/to guest memory
  x86/public: Expose physaddr_abi through Xen HVM CPUID leaf
  libxl: Add support for enabling physaddr_abi

 tools/include/libxl.h               |  5 +++++
 tools/libs/light/libxl_create.c     |  4 ++++
 tools/libs/light/libxl_types.idl    |  1 +
 tools/xl/xl_parse.c                 |  1 +
 xen/arch/x86/cpuid.c                |  3 +++
 xen/arch/x86/hvm/hvm.c              | 17 ++++++++++++++---
 xen/common/domain.c                 | 10 +++++++++-
 xen/include/public/arch-x86/cpuid.h |  2 ++
 xen/include/public/domctl.h         |  4 +++-
 xen/include/xen/sched.h             |  6 ++++++
 10 files changed, 48 insertions(+), 5 deletions(-)

-- 
2.47.2



Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



             reply	other threads:[~2025-04-18 14:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-18 14:18 Teddy Astie [this message]
2025-04-18 14:18 ` [RFC PATCH 2/4] x86/hvm: Consider phyaddr_abi when copying from/to guest memory Teddy Astie
2025-04-18 14:18 ` [RFC PATCH 3/4] x86/public: Expose physaddr_abi through Xen HVM CPUID leaf Teddy Astie
2025-04-18 14:18 ` [RFC PATCH 1/4] xen: Introduce physaddr_abi CDF flag Teddy Astie
2025-04-30 15:59   ` Jan Beulich
2025-05-02 11:55     ` Teddy Astie
2025-05-02 12:48       ` Jan Beulich
2025-04-18 14:18 ` [RFC PATCH 4/4] libxl: Add support for enabling physaddr_abi Teddy Astie
2025-04-22  7:45 ` [RFC PATCH 0/4] Physical address hypercall ABI ("HVMv2") Jan Beulich
2025-05-01 11:14   ` Julien Grall
2025-05-02 12:02     ` Teddy Astie

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.1744981654.git.teddy.astie@vates.tech \
    --to=teddy.astie@vates.tech \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --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.