[PATCH] xen/kexec: Wire up kexec hypercalls for PVH hardware domains

[PATCH] xen/kexec: Wire up kexec hypercalls for PVH hardware domains

[Andrew Cooper]

Nothing in do_kexec_op() is PV specific.  Plumb in PVH guests too.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Teddy Astie <teddy.astie@vates.tech>

kexec-tools in userspace still has a PV check needing dropping before kexec is
generally usable for PVH dom0's, but the Xen side should be all fine.

Bloat-o-meter reports:

  Function                                     old     new   delta
  hvm_hypercall                               2118    2309    +191
  hvm_do_multicall_call                       1366    1411     +45
  Total: Before=4226938, After=4227174, chg +0.01%

which reinforces my hatred of this entire infrastructure.
---
 xen/include/hypercall-defs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index a625d634b694..79ee72993dfd 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -280,7 +280,7 @@ sysctl                             do       do       do       do       do
 domctl                             do       do       do       do       do
 #endif
 #ifdef CONFIG_KEXEC
-kexec_op                           compat   do       -        -        -
+kexec_op                           compat   do       compat   do       -
 #endif
 tmem_op                            -        -        -        -        -
 #ifdef CONFIG_ARGO

base-commit: 50e7b8a32dcb1360dbe9e0fa8b81a3ad02d0b670
-- 
2.39.5

Re: [PATCH] xen/kexec: Wire up kexec hypercalls for PVH hardware domains

[Jan Beulich]

On 20.07.2026 20:58, Andrew Cooper wrote:
> Nothing in do_kexec_op() is PV specific.  Plumb in PVH guests too.

Hmm. "Nothing" is a little bold, isn't it? PVH (Dom0 or DomU) in principle have
no notion of machine addresses, yet KEXEC_RANGE_MA_* report such. Similarly
struct xen_kexec_segment and struct xen_kexec_load each have a machine address
field. Presumably these can / should be viewed more like "handles" here? If so
(and preferably with the description extended a little to cover this) ...

> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

Jan

Re: [PATCH] xen/kexec: Wire up kexec hypercalls for PVH hardware domains

[Roger Pau Monné]

On Mon, Jul 20, 2026 at 07:58:25PM +0100, Andrew Cooper wrote:
> Nothing in do_kexec_op() is PV specific.  Plumb in PVH guests too.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Teddy Astie <teddy.astie@vates.tech>
> 
> kexec-tools in userspace still has a PV check needing dropping before kexec is
> generally usable for PVH dom0's, but the Xen side should be all fine.

Yeah, I took a look into that but didn't attempt to remove the check.

However, a PVH dom0 would/could have two ways do to kexec:  it could
do a guest-only kexec (like other HVM guests), or a full host kexec
(like PV dom0).  Do we need a switch in kexec tools to signal whether
we want to perform a host vs guest kexec?  Or should we just assume
that a PVH dom0 will exclusively do host kexec?

Thanks, Roger.