]> xenbits.xensource.com Git - xen.git/log
xen.git
3 years agoxen/console: CFI hardening
Andrew Cooper [Thu, 28 Oct 2021 13:06:28 +0000 (14:06 +0100)]
xen/console: CFI hardening

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen/video: CFI hardening
Andrew Cooper [Fri, 29 Oct 2021 18:41:13 +0000 (19:41 +0100)]
xen/video: CFI hardening

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen/iommu: CFI hardening
Andrew Cooper [Fri, 29 Oct 2021 17:30:29 +0000 (18:30 +0100)]
xen/iommu: CFI hardening

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

AMD's parse_ppr_log_entry() has no external callers, so becomes static.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen/decompress: CFI hardening
Andrew Cooper [Fri, 29 Oct 2021 19:57:23 +0000 (20:57 +0100)]
xen/decompress: CFI hardening

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen/vpci: CFI hardening
Andrew Cooper [Fri, 29 Oct 2021 10:57:06 +0000 (11:57 +0100)]
xen/vpci: CFI hardening

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen/keyhandler: CFI hardening
Andrew Cooper [Thu, 28 Oct 2021 10:18:45 +0000 (11:18 +0100)]
xen/keyhandler: CFI hardening

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Tweak {IRQ_,}KEYHANDLER() to use a named initialiser instead of requiring a
pointer cast to compile in the IRQ case.

Reposition iommu_dump_page_tables() to avoid a forward declaration.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen/tasklet: CFI hardening
Andrew Cooper [Thu, 28 Oct 2021 09:58:37 +0000 (10:58 +0100)]
xen/tasklet: CFI hardening

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

The function pointer cast in hvm_vcpu_initialise() is undefined behaviour.

While it happens to function correctly, it is not compatible with control flow
typechecking, so introduce a new hvm_assert_evtchn_irq_tasklet() to handle the
parameter type conversion in a legal way.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen/hypfs: CFI hardening
Andrew Cooper [Fri, 29 Oct 2021 14:42:42 +0000 (15:42 +0100)]
xen/hypfs: CFI hardening

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Juergen Gross <jgross@suse.com>
3 years agoxen/evtchn: CFI hardening
Andrew Cooper [Fri, 29 Oct 2021 13:35:51 +0000 (14:35 +0100)]
xen/evtchn: CFI hardening

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen/sched: CFI hardening
Andrew Cooper [Thu, 28 Oct 2021 09:56:53 +0000 (10:56 +0100)]
xen/sched: CFI hardening

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Dario Faggioli <dfaggioli@suse.com>
3 years agoxsm: CFI hardening
Andrew Cooper [Fri, 29 Oct 2021 20:26:04 +0000 (21:26 +0100)]
xsm: CFI hardening

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
3 years agoxsm/flask/ss: CFI hardening
Andrew Cooper [Fri, 29 Oct 2021 14:32:08 +0000 (15:32 +0100)]
xsm/flask/ss: CFI hardening

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
3 years agoxen: CFI hardening for open_softirq()
Andrew Cooper [Fri, 29 Oct 2021 09:58:21 +0000 (10:58 +0100)]
xen: CFI hardening for open_softirq()

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen: CFI hardening for IPIs
Andrew Cooper [Thu, 28 Oct 2021 09:56:53 +0000 (10:56 +0100)]
xen: CFI hardening for IPIs

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen: CFI hardening for call_rcu()
Andrew Cooper [Thu, 28 Oct 2021 09:28:35 +0000 (10:28 +0100)]
xen: CFI hardening for call_rcu()

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen: CFI hardening for init_timer()
Andrew Cooper [Thu, 28 Oct 2021 09:42:25 +0000 (10:42 +0100)]
xen: CFI hardening for init_timer()

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen: CFI hardening for continue_hypercall_on_cpu()
Andrew Cooper [Thu, 28 Oct 2021 09:56:49 +0000 (10:56 +0100)]
xen: CFI hardening for continue_hypercall_on_cpu()

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen: CFI hardening for acpi_table_parse()
Andrew Cooper [Thu, 28 Oct 2021 10:30:00 +0000 (11:30 +0100)]
xen: CFI hardening for acpi_table_parse()

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen: CFI hardening for notifier callbacks
Andrew Cooper [Fri, 29 Oct 2021 09:11:55 +0000 (10:11 +0100)]
xen: CFI hardening for notifier callbacks

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen: CFI hardening for __initcall()
Andrew Cooper [Thu, 28 Oct 2021 09:24:13 +0000 (10:24 +0100)]
xen: CFI hardening for __initcall()

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen: CFI hardening for custom_param()
Andrew Cooper [Wed, 27 Oct 2021 13:21:51 +0000 (14:21 +0100)]
xen: CFI hardening for custom_param()

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

The "watchdog_timeout" and "cpu_type" handlers were missing __init.

The "numa", "acpi", "irq_vector_map" and "flask" handlers can skip forward
declarations by altering the custom_param() position.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen: CFI hardening for x86 hypercalls
Andrew Cooper [Thu, 21 Oct 2021 17:38:50 +0000 (18:38 +0100)]
xen: CFI hardening for x86 hypercalls

Control Flow Integrity schemes use toolchain and optionally hardware support
to help protect against call/jump/return oriented programming attacks.

Use cf_check to annotate function pointer targets for the toolchain.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agox86: Introduce support for CET-IBT
Andrew Cooper [Thu, 21 Oct 2021 17:38:50 +0000 (18:38 +0100)]
x86: Introduce support for CET-IBT

CET Indirect Branch Tracking is a hardware feature designed to provide
forward-edge control flow integrity, protecting against jump/call oriented
programming.

IBT requires the placement of endbr{32,64} instructions at the target of every
indirect call/jmp, and every entrypoint.

However, the default -fcf-protection=branch places an endbr{32,64} on every
function which far more than necessary, and reduces the quantity of protection
afforded.  Therefore, we use manual placement using the cf_check attribute.

It is necessary to check for both compiler and assembler support, as the
notrack prefix can be emitted in certain cases.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agox86/kexec: Annotate embedded data with ELF metadata
Andrew Cooper [Wed, 16 Feb 2022 18:24:43 +0000 (18:24 +0000)]
x86/kexec: Annotate embedded data with ELF metadata

Scanning for embedded endbranch instructions involves parsing the .text
disassembly.  Data in the kexec trampoline has no ELF metadata, so objdump
treats it as instructions and tries to disassemble.  Convert:

  ffff82d040396108 <compatibility_mode_far>:
  ffff82d040396108:       00 00                   add    %al,(%rax)
  ffff82d04039610a:       00 00                   add    %al,(%rax)
  ffff82d04039610c:       10 00                   adc    %al,(%rax)

  ffff82d04039610e <compat_mode_gdt_desc>:
  ffff82d04039610e:       17                      (bad)
          ...

  ffff82d040396118 <compat_mode_gdt>:
          ...
  ffff82d040396120:       ff                      (bad)
  ffff82d040396121:       ff 00                   incl   (%rax)
  ffff82d040396123:       00 00                   add    %al,(%rax)
  ffff82d040396125:       93                      xchg   %eax,%ebx
  ffff82d040396126:       cf                      iret
  ffff82d040396127:       00 ff                   add    %bh,%bh
  ffff82d040396129:       ff 00                   incl   (%rax)
  ffff82d04039612b:       00 00                   add    %al,(%rax)
  ffff82d04039612d:       9b                      fwait
  ffff82d04039612e:       cf                      iret
          ...

  ffff82d040396130 <compat_mode_idt>:
          ...

  ffff82d0403961b6 <kexec_reloc_size>:
  ffff82d0403961b6:       b6 01                   mov    $0x1,%dh
          ...

to:

  ffff82d040396108 <compatibility_mode_far>:
  ffff82d040396108:       00 00 00 00 10 00                               ......

  ffff82d04039610e <compat_mode_gdt_desc>:
  ffff82d04039610e:       17 00 00 00 00 00 00 00 00 00                   ..........

  ffff82d040396118 <compat_mode_gdt>:
          ...
  ffff82d040396120:       ff ff 00 00 00 93 cf 00 ff ff 00 00 00 9b cf 00 ................

  ffff82d040396130 <compat_mode_idt>:
  ffff82d040396130:       00 00 00 00 00 00                               ......

  ffff82d040396136 <reloc_stack>:
          ...

Most data just gains type and size metadata.

The reloc_stack label is the wrong end of the data block to have a size, so
move it to the lowest address and introduce .Lreloc_stack_base as a
replacement.  Also, fix the fact that it is misaligned by 2 bytes.

While kexec_reloc_size could gain metadata, it's use in the linker
assertion (while correct) is deeply confusing to follow.  Drop it entirely,
using a linker symbol instead to denote the end of the trampoline.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
3 years agox86: Don't use the hypercall table for calling compat hypercalls
Juergen Gross [Mon, 1 Nov 2021 15:20:10 +0000 (16:20 +0100)]
x86: Don't use the hypercall table for calling compat hypercalls

Today the *_op_compat hypercalls call the modern handler functions by
using the entries from the hypercall table. This is resulting in a
not needed indirect function call which can be avoided by using the
correct handler function directly. This is basically a revert of
commit 1252e282311734 ("x86/pv: Export pv_hypercall_table[] rather
than working around it in several ways"), which reasoning no longer
applies, as shim no longer modifies the hypercall table.

The hypercall table can now be made static as there is no external
reference to it any longer.

Commit 834cb8761051f7 ("x86/PV32: fix physdev_op_compat handling")
can be reverted, too, as using the direct call of the correct handler
is already handled fine without that patch.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
3 years agox86/pv-shim: Don't modify the hypercall table
Juergen Gross [Mon, 1 Nov 2021 15:20:09 +0000 (16:20 +0100)]
x86/pv-shim: Don't modify the hypercall table

When running as pv-shim the hypercall is modified today in order to
replace the functions for __HYPERVISOR_event_channel_op and
__HYPERVISOR_grant_table_op hypercalls.

Change this to call the related functions from the normal handlers
instead when running as shim. The performance implications are not
really relevant, as a normal production hypervisor will not be
configured to support shim mode, so the related calls will be dropped
due to optimisation of the compiler.

Note that for the CONFIG_PV_SHIM_EXCLUSIVE case there is a dummy
wrapper do_grant_table_op() needed, as in this case grant_table.c
isn't being built.

Signed-off-by: Juergen Gross <jgross@suse.com>
Split out of series.  To compile in isolation, the compat_platform_op()
prototype needs correcting, and header files need rearranging to avoid the
compat_platform_op_t/multicall_entry_compat_t guest handles being declared
multiple times.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen/xsm: Move {do,compat}_flask_op() declarations into a header
Andrew Cooper [Fri, 29 Oct 2021 22:05:25 +0000 (23:05 +0100)]
xen/xsm: Move {do,compat}_flask_op() declarations into a header

Declaring sideways like this is unsafe, because the compiler can't check that
the implementation in flask_op.c still has the same type.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
3 years agoxen/sort: Switch to an extern inline implementation
Andrew Cooper [Sat, 30 Oct 2021 21:13:55 +0000 (22:13 +0100)]
xen/sort: Switch to an extern inline implementation

There are exactly 3 callers of sort() in the hypervisor.  Callbacks in a tight
loop like this are problematic for performance, especially with Spectre v2
protections, which is why extern inline is used commonly by libraries.

Both ARM callers pass in NULL for the swap function, and while this might seem
like an attractive option at first, it causes generic_swap() to be used, which
forced a byte-wise copy.  Provide real swap functions so the compiler can
optimise properly, which is very important for ARM downstreams where
milliseconds until the system is up matters.

This is also important for Control Flow Integrity schemes (e.g. x86 CET-IBT,
ARM BTI), because tagged function(s) performing an arbitrary length swap of
two arbitrary pointers is a very valuable gadget for an attacker.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
3 years agocirrus: update FreeBSD to 12.3
Roger Pau Monne [Tue, 22 Feb 2022 13:56:29 +0000 (14:56 +0100)]
cirrus: update FreeBSD to 12.3

Switch from using a FreeBSD 12.2 to a 12.3 image.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agox86/Kconfig: introduce option to select retpoline usage
Roger Pau Monne [Fri, 18 Feb 2022 14:34:16 +0000 (15:34 +0100)]
x86/Kconfig: introduce option to select retpoline usage

Add a new Kconfig option under the "Speculative hardening" section
that allows selecting whether to enable retpoline. This depends on the
underlying compiler having retpoline support.

Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agox86/clang: add retpoline support
Roger Pau Monne [Fri, 18 Feb 2022 14:34:15 +0000 (15:34 +0100)]
x86/clang: add retpoline support

Detect whether the compiler supports clang retpoline option and enable
by default if available, just like it's done for gcc.

Note clang already disables jump tables when retpoline is enabled, so
there's no need to also pass the fno-jump-tables parameter. Also clang
already passes the return address in a register always on amd64, so
there's no need for any equivalent mindirect-branch-register
parameter.

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agox86/retpoline: split retpoline compiler support into separate option
Roger Pau Monne [Fri, 18 Feb 2022 14:34:14 +0000 (15:34 +0100)]
x86/retpoline: split retpoline compiler support into separate option

Keep the previous option as a way to signal generic retpoline support
regardless of the underlying compiler, while introducing a new
CC_HAS_INDIRECT_THUNK that signals whether the underlying compiler
supports retpoline.

No functional change intended.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agoCI: Coverity tweaks
Andrew Cooper [Sat, 19 Feb 2022 16:28:08 +0000 (16:28 +0000)]
CI: Coverity tweaks

 * Use workflow_dispatch to allow manual creation of the job.
 * Use parallel builds; the workers have two vCPUs.  Also, use the build-*
   targets rather than the ones which expand to dist-*.
 * Shrink the dependency list further.  build-essential covers make and gcc,
   while bridge-utils and iproute2 are runtime dependencies not build
   dependencies.  Alter bzip2 to libbz2-dev.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
3 years agoxen: Rename asprintf() to xasprintf()
Andrew Cooper [Sat, 19 Feb 2022 17:15:27 +0000 (17:15 +0000)]
xen: Rename asprintf() to xasprintf()

Coverity reports that there is a memory leak in
ioreq_server_alloc_rangesets().  This would be true if Xen's implementation of
asprintf() had glibc's return semantics, but it doesn't.

Rename to xasprintf() to reduce confusion for Coverity and other developers.

While at it, fix style issues.  Rearrange ioreq_server_alloc_rangesets() to
use a tabulated switch statement, and not to have a trailing space in the
rangeset name for an unknown range type.

Coverity-ID: 1472735
Coverity-ID: 1500265
Fixes: 780e918a2e54 ("add an implentation of asprintf() for xen")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
3 years agotests/resource: Initialise gnttab before xenforeignmemory_map_resource()
Andrew Cooper [Sat, 19 Feb 2022 16:59:01 +0000 (16:59 +0000)]
tests/resource: Initialise gnttab before xenforeignmemory_map_resource()

It's the 'addr' input to mmap(), and currently consuming stack rubble.

Coverity-ID: 1500115
Fixes: c7a7f14b9299 ("tests/resource: Extend to check that the grant frames are mapped correctly")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
3 years agoCI/Coverity: Do not build QEMU, SeaBIOS or OVMF
Roger Pau Monne [Fri, 18 Feb 2022 12:00:42 +0000 (13:00 +0100)]
CI/Coverity: Do not build QEMU, SeaBIOS or OVMF

Such external projects should have their own Coverity runs, and
there's not much point in also making them part of our scan (apart
from greatly increasing the amount of code scanned).

Trim the dependencies now that QEMU is not built.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agoCI: add github workflow to run Coverity scans
Roger Pau Monne [Fri, 18 Feb 2022 12:00:41 +0000 (13:00 +0100)]
CI: add github workflow to run Coverity scans

Add a workflow that performs a build like it's done by osstest
Coverity flight and uploads the result to Coverity for analysis. The
build process is exactly the same as the one currently used in
osstest, and it's also run at the same time (bi-weekly).

This has one big benefit over using osstest: we no longer have to care
about keeping the Coverity tools up to date in osstest.

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agoCI: Clean up alpine containers
Andrew Cooper [Thu, 17 Feb 2022 21:16:35 +0000 (21:16 +0000)]
CI: Clean up alpine containers

 * `apk --no-cache` is the preferred way of setting up containers, and it does
   shrink the image by a few MB.
 * Neither container needs curl-dev or automake.
 * Flex and bison are needed for Xen, so move to the Xen block.

No practical change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
3 years agoCI: Add gnu grep to alpine containers
Andrew Cooper [Tue, 15 Feb 2022 20:49:10 +0000 (20:49 +0000)]
CI: Add gnu grep to alpine containers

A forthcoming change is going to want more support than busybox's grep can
provide.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
3 years agox86: replace a few do_div() uses
Jan Beulich [Fri, 18 Feb 2022 13:47:25 +0000 (14:47 +0100)]
x86: replace a few do_div() uses

When the macro's "return value" is not used, the macro use can be
replaced by a simply division, avoiding some obfuscation.

According to my observations, no change to generated code.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agovideo/vesa: adjust (not just) command line option handling
Jan Beulich [Fri, 18 Feb 2022 13:46:27 +0000 (14:46 +0100)]
video/vesa: adjust (not just) command line option handling

Document the remaining option. Add section annotation to the variable
holding the parsed value as well as a few adjacent ones. Adjust the
types of font_height and vga_compat.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agovideo/vesa: drop "vesa-remap" command line option
Jan Beulich [Fri, 18 Feb 2022 13:45:45 +0000 (14:45 +0100)]
video/vesa: drop "vesa-remap" command line option

If we get mode dimensions wrong, having the remapping size controllable
via command line option isn't going to help much. Drop the option.

While adjusting this also
- add __initdata to the variable,
- use ROUNDUP() instead of open-coding it.

Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agovideo/vesa: drop "vesa-mtrr" command line option
Jan Beulich [Fri, 18 Feb 2022 13:45:14 +0000 (14:45 +0100)]
video/vesa: drop "vesa-mtrr" command line option

Now that we use ioremap_wc() for mapping the frame buffer, there's no
need for this option anymore. As noted in the change introducing the
use of ioremap_wc(), mtrr_add() didn't work in certain cases anyway.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agovideo/vesa: unmap frame buffer when relinquishing console
Jan Beulich [Fri, 18 Feb 2022 13:44:32 +0000 (14:44 +0100)]
video/vesa: unmap frame buffer when relinquishing console

There's no point in keeping the VA space occupied when no further output
will occur.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agox86: move .text.kexec
Jan Beulich [Fri, 18 Feb 2022 13:43:58 +0000 (14:43 +0100)]
x86: move .text.kexec

The source file requests page alignment - avoid a padding hole by
placing it right after .text.entry. On average this yields a .text size
reduction of 2k.

Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agox86: introduce ioremap_wc()
Jan Beulich [Fri, 18 Feb 2022 13:42:39 +0000 (14:42 +0100)]
x86: introduce ioremap_wc()

In order for a to-be-introduced ERMS form of memcpy() to not regress
boot performance on certain systems when video output is active, we
first need to arrange for avoiding further dependency on firmware
setting up MTRRs in a way we can actually further modify. On many
systems, due to the continuously growing amounts of installed memory,
MTRRs get configured with at least one huge WB range, and with MMIO
ranges below 4Gb then forced to UC via overlapping MTRRs. mtrr_add(), as
it is today, can't deal with such a setup. Hence on such systems we
presently leave the frame buffer mapped UC, leading to significantly
reduced performance when using REP STOSB / REP MOVSB.

On post-PentiumII hardware (i.e. any that's capable of running 64-bit
code), an effective memory type of WC can be achieved without MTRRs, by
simply referencing the respective PAT entry from the PTEs. While this
will leave the switch to ERMS forms of memset() and memcpy() with
largely unchanged performance, the change here on its own improves
performance on affected systems quite significantly: Measuring just the
individual affected memcpy() invocations yielded a speedup by a factor
of over 250 on my initial (Skylake) test system. memset() isn't getting
improved by as much there, but still by a factor of about 20.

While adding {__,}PAGE_HYPERVISOR_WC, also add {__,}PAGE_HYPERVISOR_WT
to, at the very least, make clear what PTE flags this memory type uses.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
3 years agoIOMMU/PCI: propagate get_device_group_id() failure
Jan Beulich [Fri, 18 Feb 2022 13:19:42 +0000 (14:19 +0100)]
IOMMU/PCI: propagate get_device_group_id() failure

The VT-d hook can indicate an error, which shouldn't be ignored. Convert
the hook's return value to a proper error code, and let that bubble up.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
3 years agoVT-d: replace flush_all_cache()
Jan Beulich [Fri, 18 Feb 2022 13:18:51 +0000 (14:18 +0100)]
VT-d: replace flush_all_cache()

Let's use infrastructure we have available instead of an open-coded
wbinvd() invocation.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
3 years agoVT-d / x86: re-arrange cache syncing
Jan Beulich [Fri, 18 Feb 2022 13:18:01 +0000 (14:18 +0100)]
VT-d / x86: re-arrange cache syncing

The actual function should always have lived in core x86 code; move it
there, replacing get_cache_line_size() by readily available (except very
early during boot; see the code comment) data. Also rename the function.

Drop the respective IOMMU hook, (re)introducing a respective boolean
instead. Replace a true and an almost open-coding instance of
iommu_sync_cache().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
3 years agox86/cpuid: add CPUID flag for Extended Destination ID support
Roger Pau Monné [Fri, 18 Feb 2022 08:17:47 +0000 (09:17 +0100)]
x86/cpuid: add CPUID flag for Extended Destination ID support

Introduce the CPUID flag to be used in order to signal the support for
using an extended destination ID in IO-APIC RTEs and MSI address
fields. Such format expands the maximum target APIC ID from 255 to
32768 without requiring the usage of interrupt remapping.

The design document describing the feature can be found at:

http://david.woodhou.se/15-bit-msi.pdf

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
3 years agotools/libxl: don't allow IOMMU usage with PoD
Roger Pau Monné [Fri, 18 Feb 2022 08:03:08 +0000 (09:03 +0100)]
tools/libxl: don't allow IOMMU usage with PoD

Prevent libxl from creating guests that attempts to use PoD together
with an IOMMU, even if no devices are actually assigned.

While the hypervisor could support using PoD together with an IOMMU as
long as no devices are assigned, such usage seems doubtful. There's no
guarantee the guest has PoD no longer be active, and thus a later
assignment of a PCI device to such domain could fail.

Preventing the usage of PoD together with an IOMMU at guest creation
avoids having to add checks for active PoD entries in the device
assignment paths.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
3 years agotools/xenstore: add error indicator to ring page
Juergen Gross [Fri, 18 Feb 2022 08:02:48 +0000 (09:02 +0100)]
tools/xenstore: add error indicator to ring page

In case Xenstore is detecting a malicious ring page modification (e.g.
an invalid producer or consumer index set by a guest) it will ignore
the connection of that guest in future.

Add a new error field to the ring page indicating that case. Add a new
feature bit in order to signal the presence of that error field.

Move the ignore_connection() function to xenstored_domain.c in order
to be able to access the ring page for setting the error indicator.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
3 years agox86/console: process softirqs between warning prints
Roger Pau Monné [Fri, 18 Feb 2022 08:02:16 +0000 (09:02 +0100)]
x86/console: process softirqs between warning prints

Process softirqs while printing end of boot warnings. Each warning can
be several lines long, and on slow consoles printing multiple ones
without processing softirqs can result in the watchdog triggering:

(XEN) [   22.277806] ***************************************************
(XEN) [   22.417802] WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) [   22.556029] This option is intended to aid debugging of Xen by ensuring
(XEN) [   22.696802] that all output is synchronously delivered on the serial line.
(XEN) [   22.838024] However it can introduce SIGNIFICANT latencies and affect
(XEN) [   22.978710] timekeeping. It is NOT recommended for production use!
(XEN) [   23.119066] ***************************************************
(XEN) [   23.258865] Booted on L1TF-vulnerable hardware with SMT/Hyperthreading
(XEN) [   23.399560] enabled.  Please assess your configuration and choose an
(XEN) [   23.539925] explicit 'smt=<bool>' setting.  See XSA-273.
(XEN) [   23.678860] ***************************************************
(XEN) [   23.818492] Booted on MLPDS/MFBDS-vulnerable hardware with SMT/Hyperthreading
(XEN) [   23.959811] enabled.  Mitigations will not be fully effective.  Please
(XEN) [   24.100396] choose an explicit smt=<bool> setting.  See XSA-297.
(XEN) [   24.240254] *************************************************(XEN) [   24.247302] Watchdog timer detects that CPU0 is stuck!
(XEN) [   24.386785] ----[ Xen-4.17-unstable  x86_64  debug=y  Tainted:   C    ]----
(XEN) [   24.527874] CPU:    0
(XEN) [   24.662422] RIP:    e008:[<ffff82d04025b84a>] drivers/char/ns16550.c#ns16550_tx_ready+0x3a/0x90

Fixes: ee3fd57acd ('xen: add warning infrastructure')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agorwlock: remove unneeded subtraction
Roger Pau Monné [Fri, 18 Feb 2022 08:01:27 +0000 (09:01 +0100)]
rwlock: remove unneeded subtraction

There's no need to subtract _QR_BIAS from the lock value for storing
in the local cnts variable in the read lock slow path: the users of
the value in cnts only care about the writer-related bits and use a
mask to get the value.

Note that further setting of cnts in rspin_until_writer_unlock already
do not subtract _QR_BIAS.

Originally _QR_BIAS was subtracted from the result of
atomic_add_return_acquire in order to prevent GCC from emitting an
unneeded ADD instruction. This being in the lock slow path such
optimizations don't seem likely to make any relevant performance
difference. Also modern GCC and CLANG versions will already avoid
emitting the ADD instruction.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
3 years agox86/Intel: re-indent family 6 switch() in intel_log_freq()
Jan Beulich [Fri, 18 Feb 2022 08:00:10 +0000 (09:00 +0100)]
x86/Intel: re-indent family 6 switch() in intel_log_freq()

This was left at its previous indentation by e6e3cf191d37 ("x86/Intel:
also display CPU freq for family 0xf") to ease review. Remove the now
unnecessary level of indentation.

No functional change.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
3 years agobuild: fix enforce unique symbols for recent clang version
Anthony PERARD [Fri, 18 Feb 2022 07:59:03 +0000 (08:59 +0100)]
build: fix enforce unique symbols for recent clang version

clang 6.0 and newer behave like gcc in regards for the FILE symbol, so
only the filename rather than the full path to the source file.

clang 3.8.1-24 (in our debian:stretch container) and 3.5.0-10
(in our debian:jessie container) do store the full path to the source
file in the FILE symbol.

Also we have commit 81ecb38b83 ("build: provide option to disambiguate
symbol names") which were using clang 5, and LLVM's commit f5040b9685a7
[1] ("Make .file directive to have basename only") which is part of
"llvmorg-6.0.0" tag but not "release/5.x" branch. Both suggest that
clang change of behavior happened with clang 6.0.

This means that we also need to check clang version to figure out
which command we need to use to redefine symbol.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
[1] https://github.com/llvm/llvm-project/commit/f5040b9685a760e584c576e9185295e54635d51e

3 years agobuild: rework cloc recipe
Anthony PERARD [Fri, 18 Feb 2022 07:58:52 +0000 (08:58 +0100)]
build: rework cloc recipe

We are going to make other modifications to the cloc recipe, so this
patch prepare make those modification easier.

We replace the Makefile meta programming by just a shell script which
should be easier to read and is actually faster to execute.

Instead of looking for files in "$(BASEDIR)", we use "." which is give
the same result overall. We also avoid the need for a temporary file
as cloc can read the list of files from stdin.

No change intended to the output of `cloc`.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agobuild: prepare to always invoke $(MAKE) from xen/, use $(obj)
Anthony PERARD [Fri, 18 Feb 2022 07:58:01 +0000 (08:58 +0100)]
build: prepare to always invoke $(MAKE) from xen/, use $(obj)

In a future patch, when building a subdirectory, we will set
"obj=$subdir" rather than change directory.

Before that, we add "$(obj)" and "$(src)" in as many places as
possible where we will need to know which subdirectory is been built.
"$(obj)" is for files been generated during the build, and "$(src)" is
for files present in the source tree.

For now, we set both to "." in Rules.mk and Makefile.clean.

A few places don't tolerate the addition of "./", this is because make
remove the leading "./" in targets and dependencies in rules, so these
will be change later.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com> # XSM
3 years agobuild: set ALL_OBJS in main Makefile; move prelink.o to main Makefile
Anthony PERARD [Fri, 18 Feb 2022 07:57:03 +0000 (08:57 +0100)]
build: set ALL_OBJS in main Makefile; move prelink.o to main Makefile

This is to avoid arch/$arch/Makefile having to recurse into parents
directories.

This avoid duplication of the logic to build prelink.o between arches.

In order to do that, we cut the $(TARGET) target in the main Makefile in
two, there is a "prepare" phase/target runned before starting to build
"prelink.o" which will prepare "include/" among other things, then all
the $(ALL_OBJS) will be generated in order to build "prelink.o" and
finally $(TARGET) will be generated by calling into "arch/*/" to make
$(TARGET).

Now we don't need to prefix $(ALL_OBJS) with $(BASEDIR) as it is now
only used from the main Makefile. Other changes is to use "$<" instead
of spelling "prelink.o" in the target "$(TARGET)" in both
arch/*/Makefile.

Beside "prelink.o" been at a different location, no other functional
change intended.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
3 years agoxen/docs: Document how to do passthrough without IOMMU
Stefano Stabellini [Mon, 14 Feb 2022 03:19:56 +0000 (03:19 +0000)]
xen/docs: Document how to do passthrough without IOMMU

This commit creates a new doc to document how to do passthrough without IOMMU.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
3 years agoxen/arm: if direct-map domain use native UART address and IRQ number for vPL011
Stefano Stabellini [Mon, 14 Feb 2022 03:19:55 +0000 (03:19 +0000)]
xen/arm: if direct-map domain use native UART address and IRQ number for vPL011

We always use a fix address to map the vPL011 to domains. The address
could be a problem for direct-map domains.

So, for domains that are directly mapped, reuse the address of the
physical UART on the platform to avoid potential clashes.

Do the same for the virtual IRQ number: instead of always using
GUEST_VPL011_SPI, try to reuse the physical SPI number if possible.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
3 years agoxen/arm: if direct-map domain use native addresses for GICv3
Stefano Stabellini [Mon, 14 Feb 2022 03:19:54 +0000 (03:19 +0000)]
xen/arm: if direct-map domain use native addresses for GICv3

Today we use native addresses to map the GICv3 for Dom0 and fixed
addresses for DomUs.

This patch changes the behavior so that native addresses are used for
all domain which is using the host memory layout

Considering that DOM0 may not always be directly mapped in the future,
this patch introduces a new helper "domain_use_host_layout()" that
wraps both two check "is_domain_direct_mapped(d) || is_hardware_domain(d)"
for more flexible usage.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
3 years agoxen/arm: gate make_gicv3_domU_node with CONFIG_GICV3
Penny Zheng [Mon, 14 Feb 2022 03:19:53 +0000 (03:19 +0000)]
xen/arm: gate make_gicv3_domU_node with CONFIG_GICV3

This commit gates function make_gicv3_domU_node with CONFIG_GICV3.

Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
3 years agoxen/arm: if direct-map domain use native addresses for GICv2
Stefano Stabellini [Mon, 14 Feb 2022 03:19:52 +0000 (03:19 +0000)]
xen/arm: if direct-map domain use native addresses for GICv2

Today we use native addresses to map the GICv2 for Dom0 and fixed
addresses for DomUs.

This patch changes the behavior so that native addresses are used for
all domains that are direct-mapped.

NEW VGIC has different naming schemes, like referring distributor base
address as vgic_dist_base, other than the dbase. So this patch also introduces
vgic_dist_base/vgic_cpu_base accessor to access correct distributor base
address/cpu interface base address on varied scenarios,

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
3 years agoxen/arm: add ASSERT_UNREACHABLE in allocate_static_memory
Penny Zheng [Mon, 14 Feb 2022 03:19:51 +0000 (03:19 +0000)]
xen/arm: add ASSERT_UNREACHABLE in allocate_static_memory

Helper allocate_static_memory is not meant to be reachable when built with
!CONFIG_STATIC_MEMORY, so this commit adds ASSERT_UNREACHABLE in it to catch
potential misuse.

Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
3 years agoxen/arm: introduce direct-map for domUs
Penny Zheng [Mon, 14 Feb 2022 03:19:50 +0000 (03:19 +0000)]
xen/arm: introduce direct-map for domUs

Cases where domU needs direct-map memory map:
  * IOMMU not present in the system.
  * IOMMU disabled if it doesn't cover a specific device and all the guests
are trusted. Thinking a mixed scenario, where a few devices with IOMMU and
a few without, then guest DMA security still could not be totally guaranteed.
So users may want to disable the IOMMU, to at least gain some performance
improvement from IOMMU disabled.
  * IOMMU disabled as a workaround when it doesn't have enough bandwidth.
To be specific, in a few extreme situation, when multiple devices do DMA
concurrently, these requests may exceed IOMMU's transmission capacity.
  * IOMMU disabled when it adds too much latency on DMA. For example,
TLB may be missing in some IOMMU hardware, which may bring latency in DMA
progress, so users may want to disable it in some realtime scenario.
  * Guest OS relies on the host memory layout

This commit introduces a new helper assign_static_memory_11 to allocate
static memory as guest RAM for direct-map domain.

Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
3 years agoxen/arm: introduce new helper parse_static_mem_prop and acquire_static_memory_bank
Penny Zheng [Mon, 14 Feb 2022 03:19:49 +0000 (03:19 +0000)]
xen/arm: introduce new helper parse_static_mem_prop and acquire_static_memory_bank

Later, we will introduce assign_static_memory_11 for allocating static
memory for direct-map domains, and it will share a lot common codes with
the existing allocate_static_memory.

In order not to bring a lot of duplicate codes, and also to make the whole
code more readable, this commit extracts common codes into two new helpers
parse_static_mem_prop and acquire_static_memory_bank.

Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
3 years agoxen/arm: Allow device-passthrough even the IOMMU is off
Stefano Stabellini [Mon, 14 Feb 2022 03:19:48 +0000 (03:19 +0000)]
xen/arm: Allow device-passthrough even the IOMMU is off

At the moment, we are only supporting device-passthrough when Xen has
enabled the IOMMU. There are some use cases where it is not possible to
use the IOMMU (e.g. doesn't exist, hardware limitation, performance) yet
it would be OK to assign a device to trusted domain so long they are
direct-mapped or the device doesn't do DMA.

Note that when the IOMMU is disabled, it will be necessary to add
xen,force-assign-without-iommu for every device that needs to be assigned.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Julien Grall <jgrall@amazon.com>
3 years agoxen: introduce CDF_directmap
Stefano Stabellini [Mon, 14 Feb 2022 03:19:47 +0000 (03:19 +0000)]
xen: introduce CDF_directmap

This commit introduces a new arm-specific flag CDF_directmap to specify
that a domain should have its memory direct-map(guest physical address
== host physical address) at domain creation.

Also, add a directmap flag under struct arch_domain and use it to
reimplement is_domain_direct_mapped.

For now, direct-map is only available when statically allocated memory is
used for the domain, that is, "xen,static-mem" must be also defined in the
domain configuration.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
3 years agoxen: introduce internal CDF_xxx flags for domain creation
Stefano Stabellini [Mon, 14 Feb 2022 03:19:46 +0000 (03:19 +0000)]
xen: introduce internal CDF_xxx flags for domain creation

We are passing an internal-only boolean flag at domain creation to
specify whether we want the domain to be privileged (i.e. dom0) or
not. Another flag will be introduced later in this series.

This commit extends original "boolean" to an "unsigned int" covering both
the existing "is_priv" and our new "directmap", which will be introduced later.

To make visible the relationship, we name the respective constants CDF_xxx
(with no XEN_DOMCTL_ prefix) to represent the difference with the public
constants XEN_DOMCTL_CDF_xxx.

Allocate bit 0 as CDF_privileged: whether a domain is privileged or not.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
3 years agoMAINTAINERS: make Bertrand ARM maintainer
Stefano Stabellini [Thu, 10 Feb 2022 19:08:47 +0000 (11:08 -0800)]
MAINTAINERS: make Bertrand ARM maintainer

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
Asked-by: Bertrand Marquis <bertrand.marquis@arm.com>
3 years agox86emul: fix SIMD test overriding of VBROADCASTS{S,D}
Jan Beulich [Mon, 14 Feb 2022 09:09:15 +0000 (10:09 +0100)]
x86emul: fix SIMD test overriding of VBROADCASTS{S,D}

Despite their suffixes these aren't scalar instructions, and hence the
128- and 256-bit EVEX forms may not be used without AVX512VL. Gcc11 ends
up generating such instances for simd-sg.c.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agox86emul: fix VPBLENDMW with mask and memory operand
Jan Beulich [Mon, 14 Feb 2022 09:08:38 +0000 (10:08 +0100)]
x86emul: fix VPBLENDMW with mask and memory operand

Element size for this opcode depends on EVEX.W, not the low opcode bit.
Make use of AVX512BW being a prereq to AVX512_BITALG and move the case
label there, adding an AVX512BW feature check.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agox86emul: work around gcc11 bug in SIMD tests
Jan Beulich [Mon, 14 Feb 2022 09:08:17 +0000 (10:08 +0100)]
x86emul: work around gcc11 bug in SIMD tests

Gcc11 looks to have trouble with conditional expressions used with
vector operands: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104497.
Replace two instances causing SEGV there in certain cases.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
3 years agocpuid: initialize cpuinfo with boot_cpu_data
Norbert Manthey [Mon, 14 Feb 2022 09:07:36 +0000 (10:07 +0100)]
cpuid: initialize cpuinfo with boot_cpu_data

When re-identifying CPU data, we might use uninitialized data when
checking for the cache line property to adapt the cache
alignment. The data that depends on this uninitialized read is
currently not forwarded.

To avoid problems in the future, initialize the data cpuinfo
structure before re-identifying the CPU again.

The trace to hit the uninitialized read reported by Coverity is:

bool recheck_cpu_features(unsigned int cpu)
...
    struct cpuinfo_x86 c;
    ...
    identify_cpu(&c);

void identify_cpu(struct cpuinfo_x86 *c)
...
    generic_identify(c)

static void generic_identify(struct cpuinfo_x86 *c)
...
        if (this_cpu->c_early_init)
                this_cpu->c_early_init(c); // which is early_init_intel

static void early_init_intel(struct cpuinfo_x86 *c)
...
    if (c->x86 == 15 && c->x86_cache_alignment == 64)
        c->x86_cache_alignment = 128;

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.

Signed-off-by: Norbert Manthey <nmanthey@amazon.de>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agox86/Intel: also display CPU freq for family 0xf
Jan Beulich [Mon, 14 Feb 2022 09:06:11 +0000 (10:06 +0100)]
x86/Intel: also display CPU freq for family 0xf

Actually we can do better than simply bailing for there not being any
PLATFORM_INFO MSR on these. The "max" part of the information is
available in another MSR, alongside the scaling factor (which is
encoded in similar ways to Core/Core2, and hence the decoding table can
be shared).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
3 years agox86/Intel: skip CORE_THREAD_COUNT read on family 0xf
Jan Beulich [Mon, 14 Feb 2022 09:05:38 +0000 (10:05 +0100)]
x86/Intel: skip CORE_THREAD_COUNT read on family 0xf

This avoids an unnecessary (and always somewhat scary) log message for
the recovered from #GP(0).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
3 years agox86/Intel: skip PLATFORM_INFO reads on family 0xf
Jan Beulich [Mon, 14 Feb 2022 09:04:35 +0000 (10:04 +0100)]
x86/Intel: skip PLATFORM_INFO reads on family 0xf

This avoids unnecessary (and always somewhat scary) log messages for the
recovered from #GP(0).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
3 years agoxen/serial: scif: add support for HSCIF
Volodymyr Babchuk [Tue, 8 Feb 2022 11:23:55 +0000 (11:23 +0000)]
xen/serial: scif: add support for HSCIF

HSCIF is a high-speed variant of Renesas SCIF serial interface. From
Xen point of view, they almost the same, only difference is in FIFO
size.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Acked-by: Julien Grall <jgrall@amazon.com>
3 years agox86/Intel: don't log bogus frequency range on Core/Core2 processors
Jan Beulich [Wed, 9 Feb 2022 11:52:01 +0000 (12:52 +0100)]
x86/Intel: don't log bogus frequency range on Core/Core2 processors

Models 0F and 17 don't have PLATFORM_INFO documented. While it exists on
at least model 0F, the information there doesn't match the scheme used
on newer models (I'm observing a range of 700 ... 600 MHz reported on a
Xeon E5345).

Sadly the Enhanced Intel Core instance of the table entry is not self-
consistent: The numeric description of the low 3 bits doesn't match the
subsequent more textual description in some of the cases; I'm using the
former here.

Include the older Core model 0E as well as the two other Core2 models,
none of which have respective MSR tables in the SDM.

Fixes: f6b6517cd5db ("x86: retrieve and log CPU frequency information")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
3 years agoxen: add option to disable GNTTABOP_transfer
Juergen Gross [Wed, 9 Feb 2022 11:51:05 +0000 (12:51 +0100)]
xen: add option to disable GNTTABOP_transfer

The grant table operation GNTTABOP_transfer is meant to be used in
PV device backends, and it hasn't been used in Linux since the old
Xen-o-Linux days.

Add a command line sub-option to the "gnttab" option for disabling the
GNTTABOP_transfer functionality.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
3 years agox86/mm: tidy XENMEM_{get,set}_pod_target handling
Jan Beulich [Wed, 9 Feb 2022 11:50:28 +0000 (12:50 +0100)]
x86/mm: tidy XENMEM_{get,set}_pod_target handling

Do away with the "pod_target_out_unlock" label. In particular by folding
if()-s, the logic can be expressed with less code (and no goto-s) this
way.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
3 years agox86/P2M: move map_domain_gfn() (again)
Jan Beulich [Wed, 9 Feb 2022 11:48:59 +0000 (12:48 +0100)]
x86/P2M: move map_domain_gfn() (again)

The main user is the guest walking code, so move it back there; commit
9a6787cc3809 ("x86/mm: build map_domain_gfn() just once") would perhaps
better have kept it there in the first place. This way it'll only get
built when it's actually needed (and still only once).

This also eliminates one more CONFIG_HVM conditional from p2m.c.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
3 years agox86/P2M: drop a few CONFIG_HVM
Jan Beulich [Wed, 9 Feb 2022 11:47:40 +0000 (12:47 +0100)]
x86/P2M: drop a few CONFIG_HVM

This is to make it easier to see which parts of p2m.c still aren't HVM-
specific: In one case the conditionals sat in an already guarded region,
while in the other case P2M_AUDIT implies HVM.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
3 years agox86/spec-ctrl: Support Intel PSFD for guests
Andrew Cooper [Tue, 19 Oct 2021 20:22:27 +0000 (21:22 +0100)]
x86/spec-ctrl: Support Intel PSFD for guests

The Feb 2022 microcode from Intel retrofits AMD's MSR_SPEC_CTRL.PSFD interface
to Sunny Cove (IceLake) and later cores.

Update the MSR_SPEC_CTRL emulation, and expose it to guests.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
3 years agox86/cpuid: Infrastructure for cpuid word 7:2.edx
Andrew Cooper [Thu, 27 Jan 2022 21:07:40 +0000 (21:07 +0000)]
x86/cpuid: Infrastructure for cpuid word 7:2.edx

While in principle it would be nice to keep leaf 7 in order, that would
involve having an extra 5 words of zeros in a featureset.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
3 years agotests/tsx: Extend test-tsx to check MSR_MCU_OPT_CTRL
Andrew Cooper [Thu, 10 Jun 2021 11:34:45 +0000 (12:34 +0100)]
tests/tsx: Extend test-tsx to check MSR_MCU_OPT_CTRL

This MSR needs to be identical across the system for TSX to have identical
behaviour everywhere.  Furthermore, its CPUID bit (SRBDS_CTRL) shouldn't be
visible to guests.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
3 years agox86/tsx: Cope with TSX deprecation on WHL-R/CFL-R
Andrew Cooper [Wed, 16 Sep 2020 15:15:52 +0000 (16:15 +0100)]
x86/tsx: Cope with TSX deprecation on WHL-R/CFL-R

The February 2022 microcode is formally de-featuring TSX on the TAA-impacted
client CPUs.  The backup TAA mitigation (VERW regaining its flushing side
effect) is being dropped, meaning that `smt=0 spec-ctrl=md-clear` no longer
protects against TAA on these parts.

The new functionality enumerates itself via the RTM_ALWAYS_ABORT CPUID
bit (the same as June 2021), but has its control in MSR_MCU_OPT_CTRL as
opposed to MSR_TSX_FORCE_ABORT.

TSX now defaults to being disabled on ucode load.  Furthermore, if SGX is
enabled in the BIOS, TSX is locked and cannot be re-enabled.  In this case,
override opt_tsx to 0, so the RTM/HLE CPUID bits get hidden by default.

While updating the command line documentation, take the opportunity to add a
paragraph explaining what TSX being disabled actually means, and how migration
compatibility works.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
3 years agox86/tsx: Move has_rtm_always_abort to an outer scope
Andrew Cooper [Wed, 23 Jun 2021 20:53:58 +0000 (21:53 +0100)]
x86/tsx: Move has_rtm_always_abort to an outer scope

We are about to introduce a second path which needs to conditionally force the
presence of RTM_ALWAYS_ABORT.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
3 years agox86/spec-ctrl: Clean up MSR_MCU_OPT_CTRL handling
Andrew Cooper [Wed, 19 May 2021 18:40:28 +0000 (19:40 +0100)]
x86/spec-ctrl: Clean up MSR_MCU_OPT_CTRL handling

Introduce cpu_has_srbds_ctrl as more users are going to appear shortly.

MSR_MCU_OPT_CTRL is gaining extra functionality, meaning that the current
default_xen_mcu_opt_ctrl is no longer a good fit.

Introduce two new helpers, update_mcu_opt_ctrl() which does a full RMW cycle
on the MSR, and set_in_mcu_opt_ctrl() which lets callers configure specific
bits at a time without clobbering each others settings.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
3 years agotools/configure.ac: Replace macro AC_HELP_STRING
Michal Orzel [Tue, 1 Feb 2022 17:03:21 +0000 (18:03 +0100)]
tools/configure.ac: Replace macro AC_HELP_STRING

... with AS_HELP_STRING as the former is obsolete according
to GNU autoconf 2.67 documentation.

Signed-off-by: Michal Orzel <michal.orzel@arm.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
3 years agotools/libs: Fix build dependencies
Anthony PERARD [Tue, 8 Feb 2022 10:39:59 +0000 (10:39 +0000)]
tools/libs: Fix build dependencies

Some libs' Makefile aren't loading the dependencies files *.d2.

We can load them from "libs.mk" as none of the Makefile here are
changing $(DEPS) or $(DEPS_INCLUDE) so it is fine to move the
"include" to "libs.mk".

As a little improvement, don't load the dependencies files (and thus
avoid regenerating the *.d2 files) during `make clean`.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
3 years agotools/include: remove xen-external directory
Juergen Gross [Tue, 8 Feb 2022 07:06:38 +0000 (08:06 +0100)]
tools/include: remove xen-external directory

There is no user of tools/include/xen-external/* left. Remove it.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
3 years agotools/libs/evtchn: use _xen_list.h
Juergen Gross [Tue, 8 Feb 2022 07:06:37 +0000 (08:06 +0100)]
tools/libs/evtchn: use _xen_list.h

Instead of including xen-external/bsd-sys-queue.h use the header
_xen_list.h in minios.c.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
3 years agotools/libs/toolcore: replace _xentoolcore_list.h with _xen_list.h
Juergen Gross [Tue, 8 Feb 2022 07:06:36 +0000 (08:06 +0100)]
tools/libs/toolcore: replace _xentoolcore_list.h with _xen_list.h

Remove generating _xentoolcore_list.h and use the common _xen_list.h
instead.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
3 years agotools/libs/light: replace _libxl_list.h with _xen_list.h
Juergen Gross [Tue, 8 Feb 2022 07:06:35 +0000 (08:06 +0100)]
tools/libs/light: replace _libxl_list.h with _xen_list.h

Remove generating _libxl_list.h and use the common _xen_list.h instead.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
3 years agotools/include: generate a _xen_list.h file
Juergen Gross [Tue, 8 Feb 2022 07:06:34 +0000 (08:06 +0100)]
tools/include: generate a _xen_list.h file

Today tools/include contains two basically identical header files
generated from the same source. They just differ by the used name space
and they are being generated from different Makefiles via a perl
script.

Prepare to have only one such header by using a more generic namespace
"XEN" for _xen_list.h.

As the original header hasn't been updated in the Xen tree since its
introduction about 10 years ago, and the updates of FreeBSD side have
mostly covered BSD internal debugging aids, just don't generate the
new header during build, especially as using the current FreeBSD
version of the file would require some updates of the perl script,
which are potentially more work than just doing the needed editing by
hand. Additionally this enables to remove the not needed debugging
extensions of FreeBSD.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
3 years agodom0/pvh: fix processing softirqs during memory map population
Roger Pau Monne [Mon, 7 Feb 2022 11:20:08 +0000 (12:20 +0100)]
dom0/pvh: fix processing softirqs during memory map population

Make sure softirqs are processed after every successful call to
guest_physmap_add_page. Even if only a single page is to be added,
it's unknown whether the p2m or the IOMMU will require splitting the
provided page into smaller ones, and thus in case of having to break
a 1G page into 4K entries the amount of time taken by a single of
those additions will be non-trivial. Stay on the safe side and check
for pending softirqs on every successful loop iteration.

Fixes: 5427134eae ('x86: populate PVHv2 Dom0 physical memory map')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
3 years agoxen/smp: Speed up on_selected_cpus()
Andrew Cooper [Fri, 4 Feb 2022 20:12:04 +0000 (20:12 +0000)]
xen/smp: Speed up on_selected_cpus()

cpumask_weight() is an incredibly expensive way to find if no bits are set,
made worse by the fact that the calculation is performed with the global
call_lock held.

This appears to be a missing optimisation from c/s 433f14699d48 ("x86: Clean
up smp_call_function handling.") in 2011 which dropped the logic requiring the
count of CPUs.

Switch to using cpumask_empty() instead, which will short circuit as soon as
it finds any set bit in the cpumask.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
3 years agox86/hvm: Fix boot on systems where HVM isn't available
Andrew Cooper [Fri, 4 Feb 2022 17:01:41 +0000 (17:01 +0000)]
x86/hvm: Fix boot on systems where HVM isn't available

c/s 27a63cdac388 ("x86/HVM: convert remaining hvm_funcs hook invocations to
alt-call") went too far with dropping NULL function pointer checks.

smp_callin() and S3 resume call hvm_cpu_up() unconditionally.  When the
platform doesn't support HVM, hvm_enable() exits without filling in hvm_funcs,
after which the altcall pass nukes the (now unconditional) indirect call,
causing:

  (XEN) ----[ Xen-4.17.0-10.18-d  x86_64  debug=y  Not tainted ]----
  (XEN) CPU:    1
  (XEN) RIP:    e008:[<ffff82d04034bef5>] start_secondary+0x393/0x3b7
  (XEN) RFLAGS: 0000000000010086   CONTEXT: hypervisor
  ...
  (XEN) Xen code around <ffff82d04034bef5> (start_secondary+0x393/0x3b7):
  (XEN)  ff ff 8b 05 1b 84 17 00 <0f> 0b 0f ff ff 90 89 c3 85 c0 0f 84 db fe ff ff
  ...
  (XEN) Xen call trace:
  (XEN)    [<ffff82d04034bef5>] R start_secondary+0x393/0x3b7
  (XEN)    [<ffff82d0402000e2>] F __high_start+0x42/0x60

To make matters worse, several paths including __stop_this_cpu() call
hvm_cpu_down() unconditionally too, so what happen next is:

  (XEN) ----[ Xen-4.17.0-10.18-d  x86_64  debug=y  Not tainted ]----
  (XEN) CPU:    0
  (XEN) RIP:    e008:[<ffff82d04034ab02>] __stop_this_cpu+0x12/0x3c
  (XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
  ...
  (XEN) Xen code around <ffff82d04034ab02> (__stop_this_cpu+0x12/0x3c):
  (XEN)  48 89 e5 e8 8a 1d fd ff <0f> 0b 0f ff ff 90 0f 06 db e3 48 89 e0 48 0d ff
  ...
  (XEN) Xen call trace:
  (XEN)    [<ffff82d04034ab02>] R __stop_this_cpu+0x12/0x3c
  (XEN)    [<ffff82d04034ac15>] F smp_send_stop+0xdd/0xf8
  (XEN)    [<ffff82d04034a229>] F machine_restart+0xa2/0x298
  (XEN)    [<ffff82d04034a42a>] F arch/x86/shutdown.c#__machine_restart+0xb/0x11
  (XEN)    [<ffff82d04022fd15>] F smp_call_function_interrupt+0xbf/0xea
  (XEN)    [<ffff82d04034acc6>] F call_function_interrupt+0x35/0x37
  (XEN)    [<ffff82d040331a70>] F do_IRQ+0xa3/0x6b5
  (XEN)    [<ffff82d04039482a>] F common_interrupt+0x10a/0x120
  (XEN)    [<ffff82d04031f649>] F __udelay+0x3a/0x51
  (XEN)    [<ffff82d04034d5fb>] F __cpu_up+0x48f/0x734
  (XEN)    [<ffff82d040203c2b>] F cpu_up+0x7d/0xde
  (XEN)    [<ffff82d0404543d3>] F __start_xen+0x200b/0x2618
  (XEN)    [<ffff82d0402000ef>] F __high_start+0x4f/0x60

which recurses until hitting a stack overflow.  The #DF handler, which resets
its stack on each invocation, loops indefinitely.

Reinstate the NULL function pointer checks for hvm_cpu_{up,down}(), along with
comments explaining how the helpers are used.

Fixes: 27a63cdac388 ("x86/HVM: convert remaining hvm_funcs hook invocations to alt-call")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>