Kexec is of no use without its hypercall, and that hypercall is wired up
only for PV. Allowing that code to be built when !PV therefore results in
a lot of unreachable code, violating Misra C:2012 rule 2.1.

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

--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -22,7 +22,7 @@ config X86
 	select HAS_EX_TABLE
 	select HAS_FAST_MULTIPLY
 	select HAS_IOPORTS
-	select HAS_KEXEC
+	select HAS_KEXEC if PV
 	select HAS_NS16550
 	select HAS_PASSTHROUGH
 	select HAS_PCI

On Tue, Jun 30, 2026 at 03:35:12PM +0200, Jan Beulich wrote:
> Kexec is of no use without its hypercall, and that hypercall is wired up
> only for PV. Allowing that code to be built when !PV therefore results in
> a lot of unreachable code, violating Misra C:2012 rule 2.1.

Do you know what's missing for the hypercall to be functional on HVM
environments?  We would need that for parity between PVH and PV dom0s.

Thanks, Roger.

On 30.06.2026 15:39, Roger Pau Monné wrote:
> On Tue, Jun 30, 2026 at 03:35:12PM +0200, Jan Beulich wrote:
>> Kexec is of no use without its hypercall, and that hypercall is wired up
>> only for PV. Allowing that code to be built when !PV therefore results in
>> a lot of unreachable code, violating Misra C:2012 rule 2.1.
> 
> Do you know what's missing for the hypercall to be functional on HVM
> environments?

No, and since I don't know I also didn't mean to take on enabling that mode
of operation. The Misra aspect, otoh, was simple enough to cover (without
introducing much code which later would need undoing).

Jan

On 30/06/2026 2:35 pm, Jan Beulich wrote:
> Kexec is of no use without its hypercall, and that hypercall is wired up
> only for PV. Allowing that code to be built when !PV therefore results in
> a lot of unreachable code, violating Misra C:2012 rule 2.1.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -22,7 +22,7 @@ config X86
>  	select HAS_EX_TABLE
>  	select HAS_FAST_MULTIPLY
>  	select HAS_IOPORTS
> -	select HAS_KEXEC
> +	select HAS_KEXEC if PV
>  	select HAS_NS16550
>  	select HAS_PASSTHROUGH
>  	select HAS_PCI

This might be true, but it's wrong.  kexec should be wired up for PVH
too, and I don't see any reason why it can't be.

~Andrew

On 30.06.2026 15:37, Andrew Cooper wrote:
> On 30/06/2026 2:35 pm, Jan Beulich wrote:
>> Kexec is of no use without its hypercall, and that hypercall is wired up
>> only for PV. Allowing that code to be built when !PV therefore results in
>> a lot of unreachable code, violating Misra C:2012 rule 2.1.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -22,7 +22,7 @@ config X86
>>  	select HAS_EX_TABLE
>>  	select HAS_FAST_MULTIPLY
>>  	select HAS_IOPORTS
>> -	select HAS_KEXEC
>> +	select HAS_KEXEC if PV
>>  	select HAS_NS16550
>>  	select HAS_PASSTHROUGH
>>  	select HAS_PCI
> 
> This might be true, but it's wrong.  kexec should be wired up for PVH
> too, and I don't see any reason why it can't be.

I'm happy to drop this patch if one enabling PVH surfaces. I did point out
the issue a little while back, and since nothing really happened, I thought
I'd make this patch to at least address the Misra aspect. I just don't see
myself audit the affected code paths for validity in the PVH case.

Jan