David Woodhouse [Fri, 30 Dec 2022 15:19:16 +0000 (15:19 +0000)]
tools/xenstore: Reinstate setup_database() in main()
Commit 60e2f6020d ("tools/xenstore: move the call of setup_structure()
to dom0 introduction") deferred the setup of the tdb database, but that
doesn't work very well with the -D flag which avoids initialising dom0.
We end up just segfaulting with a NULL tdb pointer on any attempted
access.
Fixes: 60e2f6020d ("tools/xenstore: move the call of setup_structure() to dom0 introduction") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Jan Beulich [Thu, 22 Dec 2022 09:07:50 +0000 (10:07 +0100)]
x86/shadow: adjust and move sh_type_to_size[]
Drop the SH_type_none entry - there are no allocation attempts with
this type, and there also shouldn't be any. Adjust the shadow_size()
alternative path to match that change. Also generalize two related
assertions.
While there move the entire table and the respective part of the comment
there to hvm.c, resulting in one less #ifdef. In the course of the
movement switch to using designated initializers.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Thu, 22 Dec 2022 09:06:57 +0000 (10:06 +0100)]
x86/PV: drop dead paging_update_paging_modes() call during Dom0 construction
The function won't ever be invoked, as paging_mode_enabled() always
returns false here due to the immediately preceding clearing of
d->arch.paging.mode. While compilers recognize this and eliminate the
call, make this explicit in the source (which likely 9a28170f2da2 ["pvh
dom0: construct_dom0 changes"] should have done right away, albeit even
before that the call looks to have been pointless - shadow mode enabling
has occurred later virtually forever).
While there also update an adjacent partly stale comment.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Thu, 22 Dec 2022 09:05:21 +0000 (10:05 +0100)]
x86/paging: fold HAP and shadow memory alloc related fields
Especially with struct shadow_domain and struct hap_domain not living in
a union inside struct paging_domain, let's avoid the duplication: The
fields are named and used in identical ways, and only one of HAP or
shadow can be in use for a domain. This then also renders involved
expressions slightly more legible.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Luca Fancellu [Thu, 22 Dec 2022 09:04:34 +0000 (10:04 +0100)]
public: misra rule 20.7 fix on memory.h
Cppcheck has found a violation of rule 20.7 for the macro
XENMEM_SHARING_OP_FIELD_MAKE_GREF, the argument "val" is used in an
expression, hence add parenthesis to the argument "val" to fix the
violation.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Luca Fancellu [Thu, 22 Dec 2022 09:04:17 +0000 (10:04 +0100)]
public: misra rule 20.7 fix on errno.h
Cppcheck has found a violation of rule 20.7 for the macro XEN_ERRNO,
while the macro parameter is never used as an expression, it doesn't
harm the code or the readability to add parenthesis, so add them.
This finding is reported also by eclair and coverity.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Michal Orzel [Mon, 19 Dec 2022 08:59:08 +0000 (09:59 +0100)]
xen/arm: Allow to set grant table related limits for dom0less domUs
At the moment, for dom0less domUs, we do not have a way to specify
per domain grant table related limits (unlike when using xl), namely
max version, max number of grant frames, max number of maptrack frames.
This means that such domains always use the values specified by the Xen
command line parameters or their default values if unspecified.
In order to have more control over dom0less domUs, introduce the
following device-tree properties that can be set under domUs nodes:
- max_grant_version to set the maximum grant table version the domain
is allowed to use,
- max_grant_frames to set the maximum number of grant frames the domain
is allowed to have,
- max_maptrack_frames to set the maximum number of grant maptrack frames
the domain is allowed to have.
Update documentation accordingly.
Note that the values obtained from device tree are of type uint32_t,
whereas the d_cfg.max_{grant_frames,maptrack_frames} are of type int32_t.
Call panic in case of overflow. Other sanity checks are already there in
grant_table_init() resulting in panic in case of errors, therefore no
need to repeat them in create_domUs().
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Sergey Dyasli [Mon, 19 Dec 2022 14:45:33 +0000 (14:45 +0000)]
x86/ucode: load microcode earlier on boot CPU
Call early_microcode_init() straight after multiboot modules become
accessible. Modify it to load the ucode directly from the blob bypassing
populating microcode_cache because xmalloc is still not available at
that point during Xen boot.
Introduce early_microcode_init_cache() for populating microcode_cache.
It needs to rescan the modules in order to find the new virtual address
of the ucode blob because it changes during the boot process, e.g.
from 0x00000000010802fc to 0xffff83204dac52fc.
While at it, drop alternative_vcall() from early_microcode_init() since
it's not useful in an __init fuction.
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Sergey Dyasli [Mon, 19 Dec 2022 14:45:32 +0000 (14:45 +0000)]
x86/ucode: allow cpu_request_microcode() to skip memory allocation
This is a preparatory step in order to do earlier microcode loading on
the boot CPU when the domain heap has not been initialized yet and
xmalloc still unavailable.
Add make_copy argument which will allow to load microcode directly from
the blob bypassing microcode_cache.
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
This allows eliminating the former. No functional change intended.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
x86: replace MTRR_* constants with X86_MT_* constants
This allows eliminating of the former, with the exception of
MTRR_NUM_TYPES. MTRR_NUM_TYPES is kept, as due to a quirk of the x86
architecture X86_MT_UCM (7) is not valid in an MTRR.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
These are not currently used, so there is no functional change. Future
patches will use these constants.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com> Acked-by: Jan Beulich <jbeulich@suse.com>
arm_smmu_disable_pasid is not currently called from anywhere in Xen, but
it is inside a section of code guarded by CONFIG_PCI_ATS, which may be
helpful in the future if the PASID feature is to be implemented. Add the
attribute __maybe_unused to the function.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com> Reviewed-by: Rahul Singh <rahul.singh@arm.com>
Julien Grall [Mon, 12 Dec 2022 09:36:31 +0000 (09:36 +0000)]
xsm/flask: mkflash.sh: Use const when generating initial_sid_to_string[]
The array initial_sid_to_string is storing pointer to literal strings
and is not meant to be modified. So change the type of the variable
to "const char * const ...[]".
Signed-off-by: Julien Grall <jgrall@amazon.com> Ack-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Michal Orzel [Fri, 16 Dec 2022 13:30:12 +0000 (14:30 +0100)]
automation: Add test jobs to run XTF hypercall xen_version test
Add test jobs in both debug and non-debug versions to run hyp-xen-version
XTF test as a dom0less domU on arm64. The purpose of this test is to
validate the functional behavior of xen_version hypercall.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Michal Orzel [Fri, 16 Dec 2022 13:30:11 +0000 (14:30 +0100)]
automation: Add support for using XTF for arm64 testing
Introduce support for using XTF on Arm to perform low-level testing.
For the purpose of the CI testing, let's use the fork [1] from upstream
XTF with implemented support for arm64 (the upstream XTF only supports
x86).
Add a new script under automation/scripts to be used by the CI XTF test
jobs to perform the following tasks:
- Compiling XTF,
- Generating u-boot script using ImageBuilder,
- Running Xen with XTF as domU in pure dom0less configuration using Qemu,
- Checking test result.
The script takes the name of the XTF test to run as a first parameter.
Edwin Török [Fri, 16 Dec 2022 18:25:20 +0000 (18:25 +0000)]
tools/ocaml/xb: Drop Xs_ring.write
This function is unusued (only Xs_ring.write_substring is used), and the
bytes/string conversion here is backwards: the C stub implements the bytes
version and then we use a Bytes.unsafe_of_string to convert a string into
bytes.
However the operation here really is read-only: we read from the string and
write it to the ring, so the C stub should implement the read-only string
version, and if needed we could use Bytes.unsafe_to_string to be able to send
'bytes'. However that is not necessary as the 'bytes' version is dropped above.
Signed-off-by: Edwin Török <edvin.torok@citrix.com> Acked-by: Christian Lindig <christian.lindig@citrix.com>
Edwin Török [Fri, 16 Dec 2022 18:25:16 +0000 (18:25 +0000)]
tools/ocaml/xenctrl: Fix unused value warning
Fixes: 8b3c06a3e5 ("tools/ocaml/xenctrl: OCaml 5 support, fix use-after-free") Signed-off-by: Edwin Török <edwin.torok@cloud.com> Acked-by: Christian Lindig <christian.lindig@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Edwin Török [Fri, 16 Dec 2022 18:25:10 +0000 (18:25 +0000)]
tools/ocaml/xb,mmap: Use Data_abstract_val wrapper
This is not strictly necessary since it is essentially a no-op currently: a
cast to void * and value *, even in OCaml 5.0.
However it does make it clearer that what we have here is not a regular OCaml
value, but one allocated with Abstract_tag or Custom_tag, and follows the
example from the manual more closely:
https://v2.ocaml.org/manual/intfc.html#ss:c-outside-head
It also makes it clearer that these modules have been reviewed for
compat with OCaml 5.0.
We cannot use OCaml finalizers here, because we want exact control over when
to unmap these pages from remote domains.
No functional change.
Signed-off-by: Edwin Török <edvin.torok@citrix.com> Acked-by: Christian Lindig <christian.lindig@citrix.com>
Andrew Cooper [Fri, 16 Dec 2022 10:46:42 +0000 (10:46 +0000)]
tools/golang: Refresh bindings following virtio changes
Fixes: 43ba5202e2ee ("libxl: add support for generic virtio device") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: George Dunlap <george.dunlap@cloud.com>
Andrew Cooper [Mon, 6 Dec 2021 19:16:23 +0000 (19:16 +0000)]
x86/boot: Relocate Xen using memcpy() directly
We can relocate Xen by reading out of the virtual mapping that we're executing
on, and write directly into the directmap. In fact, this removes one
dependency on Xen being "at 0" (the XEN_IMG_OFFSET passed as src) for
relocation to occur.
This removes all the temporary pagetable handling under the covers of
move_memory(), and results in a forward copy rather than a chunked backwards
copy (caused by move_memory() always constructing src and dst in a way to
trigger memmove() to copy backwards).
With the penultimate caller of move_memory() dropped, clean up the API. Drop
the keep boolean, folding in 0 from the final caller, and drop the return
address which has been unused since c/s 0b76ce20de85 ("x86/setup: don't
relocate the VGA hole.") in 2007.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Mon, 19 Dec 2022 10:35:25 +0000 (11:35 +0100)]
NUMA: replace phys_to_nid()
All callers convert frame numbers (perhaps in turn derived from struct
page_info pointers) to an address, just for the function to convert it
back to a frame number (as the first step of paddr_to_pdx()). Replace
the function by mfn_to_nid() plus a page_to_nid() wrapper macro. Replace
call sites by the respectively most suitable one.
While there also
- introduce a !NUMA stub, eliminating the need for Arm (and potentially
other ports) to carry one individually,
- drop the (strictly speaking wrong) "pure" attribute from the function,
- extend a condition in dump_numa() to make sure that none of the
assertions would trigger for empty or (unlikely) single-page nodes (at
the same time this also prevents the warning printk() to be issued for
every empty [e.g. CPU-only] node).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Julien Grall <jgrall@amazon.com>
Neowutran [Mon, 19 Dec 2022 10:34:16 +0000 (11:34 +0100)]
x86/time: prevent overflow with high frequency TSCs
Make sure tsc_khz is promoted to a 64-bit type before multiplying by
1000 to avoid an 'overflow before widen' bug. Otherwise just above
4.294GHz the value will overflow. Processors with clocks this high are
now in production and require this to work correctly.
Signed-off-by: Neowutran <xen@neowutran.ovh> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monné [Mon, 19 Dec 2022 10:24:14 +0000 (11:24 +0100)]
x86/vmx: implement Notify VM Exit
Under certain conditions guests can get the CPU stuck in an unbounded
loop without the possibility of an interrupt window to occur on
instruction boundary. This was the case with the scenarios described
in XSA-156.
Make use of the Notify VM Exit mechanism, that will trigger a VM Exit
if no interrupt window occurs for a specified amount of time. Note
that using the Notify VM Exit avoids having to trap #AC and #DB
exceptions, as Xen is guaranteed to get a VM Exit even if the guest
puts the CPU in a loop without an interrupt window, as such disable
the intercepts if the feature is available and enabled.
Setting the notify VM exit window to 0 is safe because there's a
threshold added by the hardware in order to have a sane window value.
Note the handling of EXIT_REASON_NOTIFY in the nested virtualization
case is passed to L0, and hence a nested guest being able to trigger a
notify VM exit with an invalid context would be able to crash the L1
hypervisor (by L0 destroying the domain). Since we don't expose VM
Notify support to L1 it should already enable the required
protections in order to prevent VM Notify from triggering in the first
place.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Roger Pau Monné [Mon, 19 Dec 2022 10:23:34 +0000 (11:23 +0100)]
x86/vmx: introduce helper to set VMX_INTR_SHADOW_NMI
Introduce a small helper to OR VMX_INTR_SHADOW_NMI in
GUEST_INTERRUPTIBILITY_INFO in order to help dealing with the NMI
unblocked by IRET case. Replace the existing usage in handling
EXIT_REASON_EXCEPTION_NMI and also add such handling to EPT violations
and page-modification log-full events.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Roger Pau Monné [Mon, 19 Dec 2022 10:22:43 +0000 (11:22 +0100)]
x86/vmx: implement VMExit based guest Bus Lock detection
Add support for enabling guest Bus Lock Detection on Intel systems.
Such detection works by triggering a vmexit, which ought to be enough
of a pause to prevent a guest from abusing of the Bus Lock.
Add an extra Xen perf counter to track the number of Bus Locks detected.
This is done because Bus Locks can also be reported by setting the bit
26 in the exit reason field, so also account for those.
Note EXIT_REASON_BUS_LOCK VMExits will always have bit 26 set in
exit_reason, and hence the performance counter doesn't need to be
increased for EXIT_REASON_BUS_LOCK handling.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Jan Beulich [Tue, 13 Dec 2022 11:36:54 +0000 (12:36 +0100)]
x86/mm: avoid phys_to_nid() calls for invalid addresses
With phys_to_nid() now actively checking that a valid node ID is on
record, the two uses in paging_init() can actually trigger at least the
2nd of the assertions there. They're used to calculate allocation flags,
but the calculated flags wouldn't be used when dealing with an invalid
(unpopulated) address range. Defer the calculations such that they can
be done with a validated MFN in hands. This also does away with the
artificial calculations of an address to pass to phys_to_nid().
Note that while the variable is provably written before use, at least
some compiler versions can't actually verify that. Hence the variable
also needs to gain a (dead) initializer.
Fixes: e9c72d524fbd ("xen/x86: Use ASSERT instead of VIRTUAL_BUG_ON for phys_to_nid") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Viresh Kumar [Thu, 15 Dec 2022 13:31:40 +0000 (19:01 +0530)]
tools/libxl: Fix virtio build error for 32-bit platforms
The field 'base' in 'struct libxl_device_virtio' is defined as uint64,
while we are printing it with '%lu', which is 32bit only 32-bit
platforms. And so generates a error like:
libxl_internal.h:4388:51: error: format '%lu' expects argument of type 'long
unsigned int', but argument 3 has type 'uint64_t' {aka 'long long unsigned
int'} [-Werror=format=]
Fix it by switching to a 64bit PRI instead.
While fixing this, switch from decimal to hex which is the more natural base
to use for a field like this.
Fixes: 43ba5202e2ee ("libxl: add support for generic virtio device") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
This makes the code much easier to understand. No functional change
intended. As per Andrew Cooper, the existing logic is questionable, but
this does not make it any worse.
Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Julien Grall [Thu, 15 Dec 2022 11:45:18 +0000 (11:45 +0000)]
xen/arm: mm: Allow dump_hyp_walk() to work on the current root table
dump_hyp_walk() is used to print the tables walk in case of the data or
instruction abort.
Those abort are not limited to the runtime and could happen at early
boot. However, the current implementation of dump_hyp_walk() check
that the TTBR matches the runtime page tables.
Therefore, early abort will result to a secondary abort and not
print the table walks.
Given that the function is called in the abort path, there is no
reason for us to keep the BUG_ON() in any form. So drop it.
Julien Grall [Thu, 15 Dec 2022 11:44:54 +0000 (11:44 +0000)]
xen/arm: mm: Allow xen_pt_update() to work with the current root table
At the moment, xen_pt_update() will only work on the runtime page tables.
In follow-up patches, we will also want to use the helper to update
the boot page tables.
All the existing callers of xen_pt_update() expects to modify the
current page-tables. Therefore, we can read the root physical address
directly from TTBR0_EL2.
We have 3 violations of MISRA C Rule 4.1 ("Octal and hexadecimal escape
sequences shall be terminated") in xen/arch/arm/efi/efi-boot.h. Fix them
and take the opportunity to declare them as static const __initconst and
improve the style.
One can now use GICv3 on AArch32 systems. However, ITS is not supported.
The reason being currently we are trying to validate GICv3 on an AArch32_v8R
system. Refer ARM DDI 0568A.c ID110520, B1.3.1,
"A Generic Interrupt Controller (GIC) implemented with an Armv8-R PE must not
implement LPI support."
By default GICv3 is disabled on AArch32 and enabled on AArch64.
Updated SUPPORT.md to state that GICv3 on Arm32 is not security supported.
xen/Arm: GICv3: Define macros to read/write 64 bit
On AArch32, ldrd/strd instructions are not atomic when used to access MMIO.
Furthermore, ldrd/strd instructions are not decoded by Arm when running as
a guest to access emulated MMIO region.
Thus, we have defined readq_relaxed_non_atomic()/writeq_relaxed_non_atomic()
which in turn calls readl_relaxed()/writel_relaxed() for the lower and upper
32 bits.
For AArch64, readq_relaxed_non_atomic()/writeq_relaxed_non_atomic() invokes
readq_relaxed()/writeq_relaxed() respectively.
As GICv3 registers (GICD_IROUTER, GICR_TYPER) can be accessed in a non atomic
manner, so we have used readq_relaxed_non_atomic()/readq_relaxed_non_atomic().
However, the following points are noted for the non atomic access :-
1. In gicv3_dist_init(), using non atomic write on GICD_IROUTER is fine as this
gets invoked when interrupts are disabled.
2. In gicv3_populate_rdist(), using non atomic read on GICR_TYPER is fine as
the register is read and the interrupts are disabled as well.
3. In gicv3_irq_set_affinity(), using non atomic write on GICD_IROUTER. This
may be called with interrupts enabled. So, a non-atomic access (on AArch32)
means the GIC will see a transient value when only one of two 32-bit will be
updated. However, only AFF3 is defined in the upper 32 bits and they are 0, so
this will never change.
On AArch64, writeq_relaxed_non_atomic() invokes writeq_relaxed() (which is
atomic), so this problem does not arise.
xen/Arm: GICv3: Define remaining GIC registers for AArch32
Define missing assembly aliases for GIC registers on arm32, taking the ones
defined already for arm64 as a base. Aliases are defined according to the
GIC Architecture Specification ARM IHI 0069H.
Defined the following registers:-
1. Interrupt Controller Interrupt Priority Mask Register
2. Interrupt Controller System Register Enable register
3. Interrupt Controller Deactivate Interrupt Register
4. Interrupt Controller End Of Interrupt Register 1
5. Interrupt Controller Interrupt Acknowledge Register 1
6. Interrupt Controller Binary Point Register 1
7. Interrupt Controller Control Register
8. Interrupt Controller Interrupt Group 1 Enable register
9. Interrupt Controller Maintenance Interrupt State Register
10. Interrupt Controller End of Interrupt Status Register
11. Interrupt Controller Empty List Register Status Register
12. Interrupt Controller Virtual Machine Control Register
xen/Arm: GICv3: Define ICH_AP0R<n> and ICH_AP1R<n> for AArch32
Adapt save_aprn_regs()/restore_aprn_regs() for AArch32.
For which we have defined the following registers:-
1. Interrupt Controller Hyp Active Priorities Group0 Registers 0-3
2. Interrupt Controller Hyp Active Priorities Group1 Registers 0-3
Refer "Arm IHI 0069H ID020922", 12.4.6, Interrupt Controller List Registers
AArch64 System register ICH_LR<n>_EL2 bits [31:0] are architecturally
mapped to AArch32 System register ICH_LR<n>[31:0].
AArch64 System register ICH_LR<n>_EL2 bits [63:32] are architecturally
mapped to AArch32 System register ICH_LRC<n>[31:0].
Defined ICH_LR<0...15>_EL2 and ICH_LRC<0...15>_EL2 for AArch32.
For AArch32, the link register is stored as :-
(((uint64_t) ICH_LRC<0...15>_EL2) << 32) | ICH_LR<0...15>_EL2
Also, ICR_LR macros need to be modified as ULL is 64 bits for AArch32 and
AArch64.
xen/Arm: vGICv3: Fix emulation of ICC_SGI1R on AArch32
Refer Arm IHI 0069H ID020922, 12.5.23, ICC_SGI1R is a 64 bit register on
AArch32 systems. Thus, the function needs to change to reflect this.
The reason being 'register_t' is defined as 'u32' on AArch32.
xen/Arm: GICv3: Fix GICR_{PENDBASER, PROPBASER} emulation on 32-bit host
'unsigned long long' is defined as 64 bit across both AArch32 and AArch64.
So, use 'ULL' for 64 bit word instead of UL which is 32 bits for AArch32.
GICR_PENDBASER and GICR_PROPBASER both are 64 bit registers.
xen/Arm: vGICv3: Adapt emulation of GICR_TYPER for AArch32
Refer ARM DDI 0487I.a ID081822, G8-9650, G8.2.113
Aff3 does not exist on AArch32.
Also, refer ARM DDI 0406C.d ID040418, B4-1644, B4.1.106
Aff3 does not exist on Armv7 (ie arm32).
Thus, access to aff3 has been protected with "#ifdef CONFIG_ARM_64".
Also, v->arch.vmpidr is a 32 bit register on AArch32. So, we have assigned it to
'uint64_t vmpidr' to perform the shifts.
xen/Arm: vreg: Support vreg_reg64_* helpers on AArch32
In some situations (e.g. GICR_TYPER), the hypervior may need to emulate
64bit registers in AArch32 mode. In such situations, the hypervisor may
need to read/modify the lower or upper 32 bits of the 64 bit register.
In AArch32, 'unsigned long' is 32 bits. Thus, we cannot use it for 64 bit
registers.
While we could replace 'unsigned long' by 'uint64_t', it is not entirely clear
whether a 32-bit compiler would not allocate register for the upper 32-bit.
Therefore fold vreg_reg_* helper in the size specific one and use the
appropriate type based on the size requested.
xen/Arm: GICv3: Do not calculate affinity level 3 for AArch32
Refer ARM DDI 0487I.a ID081822, G8-9817, G8.2.169
Affinity level 3 is not present in AArch32.
Also, refer ARM DDI 0406C.d ID040418, B4-1644, B4.1.106,
Affinity level 3 is not present in Armv7 (ie arm32).
Thus, any access to affinity level 3 needs to be guarded within
"ifdef CONFIG_ARM_64".
AMD's XHCI has BAR0 of 1M (compared to 64K on Intel). Map it as a whole
(reserving more space in the fixmap). Make fixmap slot conditional on
CONFIG_XHCI.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Viresh Kumar [Wed, 14 Dec 2022 11:03:09 +0000 (12:03 +0100)]
libxl: add support for generic virtio device
This patch adds basic support for configuring and assisting generic
Virtio backends, which could run in any domain.
An example of domain configuration for mmio based Virtio I2C device is:
virtio = ["type=virtio,device22,transport=mmio"]
To make this work on Arm, allocate Virtio MMIO params (IRQ and memory
region) and pass them to the backend and update guest device-tree to
create a DT node for the Virtio devices.
Add special support for I2C and GPIO devices, which require the
"compatible" DT property to be set, among other device specific
properties. Support for generic virtio devices is also added, which just
need a MMIO node but not any special DT properties, for such devices the
user needs to pass "virtio,device" in the "type" string.
The parsing of generic virtio device configurations will be done in a
separate commit.
Juergen Gross [Wed, 14 Dec 2022 11:02:21 +0000 (12:02 +0100)]
tools/xenstore: enhance hashtable implementation
Today it is possible to set a flag when calling hashtable_destroy() in
order to specify whether the data associated with the hashtable entries
should be freed or not. The keys of the entries will always be freed.
Change that by replacing the flag of hashtable_destroy() by two flags
for create_hashtable() which will specify whether the data and/or the
key of each entry should be freed or not.
This will enable users to have the key e.g. as part of the data.
Add a new function hashtable_iterate() to call a user specified
function for each entry in the hashtable.
Add new primes to the primetable in order to support smaller sizes of
the hashtable. The primes are selected according to:
https://planetmath.org/goodhashtableprimes
Update the URL in the source as the old one wasn't correct any longer.
Use abort() instead of just _exit() in libxl__alloc_failed(). This
is more friendly for debugging, as it will trap into debugger,
systemd-coredump will collect coredump/backtrace etc. It's much more
useful than just "libxl: FATAL ERROR: memory allocation failure (...)"
message without context where it actually failed.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Luca Fancellu [Wed, 7 Dec 2022 13:07:04 +0000 (13:07 +0000)]
xen: Justify linker script defined symbols in include/xen/kernel.h
Eclair and Coverity found violation of the MISRA rule 8.6 for the
symbols _start, _end, start, _stext, _etext, _srodata, _erodata,
_sinittext, _einittext which are declared in
xen/include/xen/kernel.h.
All those symbols are defined by the liker script so we can deviate
from the rule 8.6 for these cases.
Luca Fancellu [Wed, 7 Dec 2022 13:07:03 +0000 (13:07 +0000)]
tools/misra: fix skipped rule numbers
MISRA rules are in the format Rule X.Y, currently the script
convert_misra_doc.py is using two nested loop through range(1,22) to
enumerate rules that needs to be skipped, using combination of X.Y in
that range, however there are two issues in the code:
- rule 22 is never included because the range(1,22) produces a range
in [1..21]
- the second issue is that the code is producing invalid MISRA C 2012
rules, for example 1.21 and so on
Fix the issue using a dictionary that list the rules in misra c2012.
Fixes: 57caa5375321 ("xen: Add MISRA support to cppcheck make rule") Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Stefano Stabellini <sstabellini@kernel.org>
Luca Fancellu [Wed, 7 Dec 2022 13:07:02 +0000 (13:07 +0000)]
xen/Makefile: remove Cppcheck invocation from the Makefile
The script xen-analysis.py is going to be used for the analysis with
cppcheck, so remove the rules from the Makefile.
The python script xen/tools/merge_cppcheck_reports.py was used by the
makefile rules, but its functionality is integrated in the
xen-analysis.py script now, so it can be removed.
Remove some entry from the .gitignore related to Cppcheck invocation
from Makefile.
This is a partial revert of commit 43aa3f6e72d34 where the entry
xen/xen-cppcheck.xml from .gitignore is reverted because its path has
changed, *.c.cppcheck entry is not needed anymore either,
merge_cppcheck_reports.py script is reverted for the reason above,
all makefile changes are reverted.
Every other change to processor.h, config.h, kconfig.h is kept because
they are used with the new process.
This is a partial revert of commit 57caa53753212 where Makefile changes
are reverted, convert_misra_doc.py script is kept as it is used with the
new process.
Luca Fancellu [Wed, 7 Dec 2022 13:07:01 +0000 (13:07 +0000)]
xen/scripts: add cppcheck tool to the xen-analysis.py script
Add Cppcheck analysis to the xen-analysis.py script using the
arguments --run-cppcheck.
Now cppcheck analysis will build Xen while the analysis is performed
on the source files, it will produce a text report and an additional
html output when the script is called with --cppcheck-html.
With this patch cppcheck will benefit of platform configuration files
that will help it to understand the target of the compilation and
improve the analysis. These are XML files placed in
xen/tools/cppcheck-plat/, describing to cppcheck the length of basic
types to help it in the analysis.
To do so:
- Update xen-analysis.py with the code to integrate cppcheck.
- add platform configuration files for cppcheck..
- add cppcheck-cc.sh script that is a wrapper for cppcheck and it's
used as Xen compiler, it will intercept all flags given from the
make build system and it will execute cppcheck on the compiled
file together with the file compilation.
- guarded hypercall-defs.c with CPPCHECK define because cppcheck
gets confused as the file does not contain c code.
- add false-positive-cppcheck.json file
- update documentation.
- update .gitignore
Luca Fancellu [Wed, 7 Dec 2022 13:07:00 +0000 (13:07 +0000)]
xen/scripts: add xen-analysis.py for coverity and eclair analysis
Add new script for coverity/eclair analysis tool that will enable
the procedure to suppress findings when these tool are used.
The procedure is documented in docs/misra/documenting-violations.rst
and the script is documented in docs/misra/xen-static-analysis.rst.
Add in docs/misra/ the files safe.json and
false-positive-{coverity,eclair}.json that are JSON files containing
the data structures for the justifications, they are used by the
analysis script to link the Xen tags to the proprietary tool comment.
Add docs/misra/documenting-violations.rst to explain how to add
justifications.
Add docs/misra/xen-static-analysis.rst to explain how to use the
script to analyse Xen.
Jan Beulich [Mon, 12 Dec 2022 11:27:30 +0000 (12:27 +0100)]
x86/tboot: actually wipe contexts
Especially with our use of __builtin_memset() to implement memset() the
compiler is free to eliminate instances when it can prove that the
affected object is dead. Introduce a small helper function accompanying
the memset() with a construct forcing the compiler to retain the
clearing of (stack) memory.
Fixes: c021c95498d9 ("x86: Replace our own specialised versions of memset and memcpy with") Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Jason Andryuk <jandryuk@gmail.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Mon, 12 Dec 2022 11:21:01 +0000 (12:21 +0100)]
x86/tboot: correct IOMMU (VT-d) interaction
First of all using is_idle_domain() on the subject domain in the body of
for_each_domain() is pointless. Replace that conditional by one checking
that a domain actually has IOMMU support enabled for it, and that we're
actually on a VT-d system (both are largely cosmetic / documentary with
how things work elsewhere, but still).
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Mon, 12 Dec 2022 11:19:20 +0000 (12:19 +0100)]
x86/mm: PGC_shadowed_pt is used by shadow code only
By defining the constant to zero when !SHADOW_PAGING we give compilers
the chance to eliminate a little more dead code elsewhere in the tree.
Plus, as a minor benefit, the general reference count can be one bit
wider. (To simplify things, have PGC_shadowed_pt change places with
PGC_extra.)
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Mon, 12 Dec 2022 11:18:41 +0000 (12:18 +0100)]
x86/mm: rename PGC_page_table to PGC_shadowed_pt
The original name didn't express the purpose of the flag: It is being
set once a page table page obtains a shadow, and it is removed when the
last shadow of a page was destroyed.
In set_tlbflush_timestamp() also remove the 2nd half of the condition as
being redundant (PGC_shadowed_pt can't be set on a page without shadow
mode being enabled on the owning domain).
Requested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Mon, 12 Dec 2022 11:17:07 +0000 (12:17 +0100)]
x86/tboot: drop failed attempt to hash shadow page tables
While plausible to do what was intended based on the name of the flag
(PGC_page_table), that name was misleading and is going to be changed.
It marks page tables pages _having_ a shadow, not shadows of page table
pages. The attempt also didn't cover the HAP case at all, and it
constituted a potentially very long loop doing nothing when
!SHADOW_PAGING. Instead leave a comment of what actually wants doing
there (which then also may need to account for e.g. the risk of A/D bits
becoming set behind our backs).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Wei Chen [Mon, 12 Dec 2022 11:15:28 +0000 (12:15 +0100)]
xen: introduce a Kconfig option to configure NUMA nodes number
Currently the maximum number of NUMA nodes is a hardcoded value.
This provides little flexibility unless changing the code.
Introduce a new Kconfig option to change the maximum number of
NUMA nodes conveniently. Also considering that not all
architectures support NUMA, this Kconfig option is only visible
on NUMA enabled architectures. Architectures not supporting NUMA
still use 1 for MAX_NUMNODES.
As NODES_SHIFT is currently unused, we're taking this
opportunity to remove it.
Signed-off-by: Wei Chen <wei.chen@arm.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Wei Chen [Mon, 12 Dec 2022 11:14:53 +0000 (12:14 +0100)]
xen/x86: move NUMA process nodes nodes code from x86 to common
x86 has implemented a set of codes to process NUMA nodes. These
codes will parse NUMA memory and processor information from
ACPI SRAT table. But except some ACPI specific codes, most
of the process code like memory blocks validation, node memory
range updates and some sanity check can be reused by other
NUMA implementation.
So in this patch, we move some variables and related functions
for NUMA memory and processor to common as library. At the
same time, numa_set_processor_nodes_parsed has been introduced
for ACPI specific code to update processor parsing results.
With this helper, we can reuse most of NUMA memory affinity init
code from ACPI. As bad_srat and node_to_pxm functions have been
used in common code to do architectural fallback and node to
architectural node info translation. But it doesn't make sense
to reuse the functions names in common code, we have rename them
to neutral names as well.
PXM is an ACPI specific item, we can't use it in common code
directly. So we introduced an numa_fw_nid_name for each NUMA
implementation to set their specific firmware NUMA node name.
In this case, we do not need to retain a lot of per-arch code
but still can print architectural log messages for different
NUMA implementations. A default value "???" will be set to
indicate an unset numa_fw_nid_name.
mem_hotplug is accessed by common code if memory hotplug is
activated. Even if this is only supported by x86, export the
variable so that other architectures could support it in the future.
As asm/acpi.h has been removed from common/numa.c, we have to
move NR_NODE_MEMBLKS from asm/acpi.h to xen/numa.h in this patch
as well.
Signed-off-by: Wei Chen <wei.chen@arm.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Wei Chen [Mon, 12 Dec 2022 11:14:13 +0000 (12:14 +0100)]
xen/x86: use arch_get_ram_range to get information from E820 map
The sanity check of nodes_cover_memory is also a requirement of
other architectures that support NUMA. But now, the code of
nodes_cover_memory is tied to the x86 E820. In this case, we
introduce arch_get_ram_range to decouple architecture specific
memory map from this function. This means, other architectures
like Arm can also use it to check its node and memory coverage
from bootmem info.
Depends arch_get_ram_range, we make nodes_cover_memory become
architecture independent. We also use neutral words to replace
SRAT and E820 in the print message of this function. This will
to make the massage seems more common.
As arch_get_ram_range use unsigned int for index, we also adjust
the index in nodes_cover_memory from int to unsigned int.
Signed-off-by: Wei Chen <wei.chen@arm.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Wei Chen [Mon, 12 Dec 2022 11:13:26 +0000 (12:13 +0100)]
xen/x86: Use ASSERT instead of VIRTUAL_BUG_ON for phys_to_nid
VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
results in two lines of error-checking code in phys_to_nid
that is not actually working and causing two compilation
errors:
1. error: "MAX_NUMNODES" undeclared (first use in this function).
This is because in the common header file, "MAX_NUMNODES" is
defined after the common header file includes the ARCH header
file, where phys_to_nid has attempted to use "MAX_NUMNODES".
This error was resolved after we moved the phys_to_nid from
x86 ARCH header file to common header file.
2. error: wrong type argument to unary exclamation mark.
This is because, the error-checking code contains !node_data[nid].
But node_data is a data structure variable, it's not a pointer.
So, in this patch, we use ASSERT instead of VIRTUAL_BUG_ON to
enable the two lines of error-checking code. And fix the left
compilation errors by replacing !node_data[nid] to
!node_data[nid].node_spanned_pages. Although NUMA allows one node
can only have CPUs but without any memory. And node with 0 bytes
of memory might have an entry in memnodemap[] theoretically. But
that doesn't mean phys_to_nid can find any valid address from a
node with 0 bytes memory.
Wei Chen [Mon, 12 Dec 2022 11:11:55 +0000 (12:11 +0100)]
xen/x86: move generically usable NUMA code from x86 to common
There are some codes in x86/numa.c can be shared by common
architectures to implememnt NUMA support. Just like some
variables and functions to check and store NUMA memory map.
And some variables and functions to do NUMA initialization.
In this patch, we move them to common/numa.c and xen/numa.h
and use the CONFIG_NUMA to gate them for non-NUMA supported
architectures. As the target header file is Xen-style, so
we trim some spaces and replace tabs for the codes that has
been moved to xen/numa.h at the same time.
As acpi_scan_nodes has been used in a common function, it
doesn't make sense to use acpi_xxx in common code, so we
rename it to numa_process_nodes in this patch too. After that
if we still use CONFIG_ACPI_NUMA in to gate numa_process_nodes
in numa_initmem_init, that doesn't make sense. As CONFIG_NUMA
will be selected by CONFIG_ACPI_NUMA for x86. So, we replace
CONFIG_ACPI_NUMA by CONFIG_NUMA to gate numa_process_nodes.
As arch_numa_disabled has been implememnted for ACPI NUMA,
we can rename srat_disabled to numa_disabled and move it
to common code as well.
The macro node_to_first_cpu(node) hasn't been used anywhere,
so we drop it in this patch too.
Because some architectures allow to use all 64 physical address
bits, but some architectures are not (like Arm64 allows 52, 48
bits). In this case, we use min(PADDR_BITS, BITS_PER_LONG - 1)
to calculate the shift when only one node is in the system in
this patch too.
Signed-off-by: Wei Chen <wei.chen@arm.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Wei Chen [Mon, 12 Dec 2022 11:10:18 +0000 (12:10 +0100)]
xen/x86: Provide helpers for common code to access acpi_numa
acpi_numa is a specific NUMA switch for ACPI NUMA implementation.
Other NUMA implementation may not need this switch. But this switch is
not only used by ACPI code, it is also used directly in some general
NUMA logic code. So far this hasn't caused any problem because Xen only
has x86 implementing ACPI NUMA, but now Arm is implementing device tree
based NUMA. Accesssing acpi_numa directly in some functions will be a
block of reusing NUMA common code. It is also difficult for us to replace
it with a new generic switch, because it is hard to prove that the new
switch states can guarantee the original code will work correctly.
So in this patch, we provide two helpers for common code to update and
get states of acpi_numa. And other new NUMA implementations just need
to provide the same helpers for common code. In this case, the generic
NUMA logic code can be reused by all NUMA implementations.
Signed-off-by: Wei Chen <wei.chen@arm.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Fix several MISRA Issues Rule 8.4 ("A compatible declaration shall be
visible when an object or function with external linkage is defined")
found by cppcheck affecting xen/xsm/flask.
- policydb_loaded_version is not declared; removed it because it is
unused
- move ss_initialized declaration to xen/xsm/flask/include/conditional.h
- #include <conditional.h> (which is
xen/xsm/flask/include/conditional.h) in xen/xsm/flask/ss/policydb.c so
that policydb.c also gets the declaration of ss_initialized
- #include <conditional.h> in xen/xsm/flask/ss/services.c to declare
security_*_bools functions that services.c is defining and using
This patch solves all the Rule 8.4 violations found by cppcheck on xsm/
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Michal Orzel [Thu, 1 Dec 2022 14:25:32 +0000 (14:25 +0000)]
automation: Add CI test jobs for Yocto
Populate test jobs for Yocto based tests using the provided containers.
Due to the size restrictions, it is currently not possible to split the
build and run tasks, therefore everything is done in a single step.
Test jobs for the supported Yocto targets are generic to avoid the
necessity to add new ones after each Yocto release. The only thing
required to be changed after updating the containers is the variable
YOCTO_VERSION stored in a .yocto-test template.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Add make clean support to remove the containers from the local docker
registry.
make clean-<image_name> must be called to remove an image:
make clean-yocto/kirkstone-qemuarm: remove yocto kirkstone for qemuarm
image
Add containers suitable to run yocto kirkstone build based on ubuntu
22.04. It contains all packages required by Yocto and a checkout of the
layers required to build Xen with Yocto.
Add a generic docker image template to be used to automatically generate
docker files for different configurations:
- specific yocto version
- different targets (qemu arm, arm64 and x86)
- different host platforms (x86 or arm64)
During a call to 'make all', only the images for the host platform we
run it on in the CI is generated.
If needed, images for an other host platform can be generated manually
by calling the right make target (see make help).
Add a build script to build and run xen on qemu using Yocto.
The script supports arm32, arm64 and x86_64 and checks that dom0 is
properly booting. At this stage this does not run any guest on top of
dom0. The script is to be executed in one of the docker images to build
and run a system using a Xen source tree.
Add automation/build/yocto/*.dockerfile to gitignore as those files are
generated.
Add SPDX license information to all the *.c files under arch/arm.
The SPDX tags added by this patch were chosen based on the existing
copyright headers. When the copyright header was missing we used the
default license which is GPLv2 for Xen (as per the COPYING file).
One exception is domain_page.c which is a split from mm.c so the license
is GPLv2+.
Michal Orzel [Thu, 17 Nov 2022 16:16:42 +0000 (17:16 +0100)]
automation: Install packages required by tests in containers
Installation of additional packages from the test scripts when running
the tests has some drawbacks. It is slower than cloning containers and can
fail due to some network issues (apparently it often happens on x86
rackspace). This patch is adding the packages required by the tests to be
installed when building the containers.
>From qemu-alpine-x86_64.sh into debian:stretch:
- cpio,
- busybox-static.
Andrew Cooper [Mon, 6 Dec 2021 13:54:38 +0000 (13:54 +0000)]
x86/boot: Drop pte_update_limit from physical relocation logic
This check has existed in one form or another since c/s 369bafdb1c1 "xen: Big
changes to x86 start-of-day" in 2007.
c/s 0d31d1680868 "x86/setup: do not relocate Xen over current Xen image
placement" demonstrates clearly that the logic was broken.
Without dissecting the myriad changes over the past 14 years, I'm pretty
certain Xen only booted by accident when l2_xenmap[0] was handled specially
and skipped the pte_update_limit check which would have left it corrupt.
The old logic was simply not safe, even if implemented as intended. TLB
entries can be lost for any reason; architectural (e.g. SMI), or uarch
(e.g. enough OoO execution to thrash the TLB). It is never safe to have
non-pagetable data in your live pagetables, for any period of time.
Either way, since c/s 0d31d1680868 there is not a partial overlap of the Xen
image, so drop the vestigial remnants.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Michal Orzel [Fri, 28 Oct 2022 12:49:37 +0000 (14:49 +0200)]
xen/arm: Do not route NS phys timer IRQ to Xen
At the moment, we route NS phys timer IRQ to Xen even though it does not
make use of this timer. Xen uses hypervisor timer for itself and the
physical timer is fully emulated, hence there is nothing that can trigger
such IRQ. This means that requesting/releasing IRQ ends up as a deadcode
as it has no impact on the functional behavior, whereas the code within
a handler ends up being unreachable. This is a left over from the early
days when the CNTHP IRQ was buggy on the HW model used for testing and we
had to use the CNTP instead.
Remove the calls to {request/release}_irq for this timer as well as the
code within the handler. Since timer_interrupt handler is now only used
by the CNTHP, refactor it as follows:
- rename it to htimer_interrupt to reflect its purpose,
- remove the IRQ affiliation test,
- invert the condition to avoid indented code and use unlikely,
- improve readability by adding new lines \btw code and comments.
Keep the calls to zero the CNTP_CTL_EL0 register for sanity and also
remove the corresponding perf counter definition.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Julien Grall <jgrall@amazon.com>
A previous patch tried to get Linux to use the ESRT under Xen if it is
in memory of type EfiRuntimeServicesData. However, this turns out to be
a bad idea. Ard Biesheuvel pointed out that EfiRuntimeServices* memory
winds up fragmenting both the EFI page tables and the direct map, and
that EfiACPIReclaimMemory is a much better choice for this purpose.
Andrew Cooper [Tue, 26 Jul 2022 11:53:20 +0000 (12:53 +0100)]
x86/tboot: Drop mfn_in_guarded_stack()
To support CET Shadow Stacks, guard pages changed unilaterally from being
holes to being read-only (i.e. they're never holes any more).
Furthermore, being real shadow stacks in some cases, the frames explicitly
should be included in the integrity check.
Fixes: 60016604739b ("x86/shstk: Rework the stack layout to support shadow stacks") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Michal Orzel [Wed, 7 Dec 2022 11:18:36 +0000 (12:18 +0100)]
x86/platform: protect XENPF_get_dom0_console if CONFIG_VIDEO not set
A build failure [1] is observed if CONFIG_VGA (and thus CONFIG_VIDEO) is
not set. This is because XENPF_get_dom0_console cmd of platform hypercall
makes a call to fill_console_start_info, which is defined in video/vga.c
and built only if CONFIG_VGA is set.
To fix this issue, protect XENPF_get_dom0_console with CONFIG_VIDEO
ifdefery.
[1]:
ld: prelink.o: in function `do_platform_op':
(.text.do_platform_op+0x1a7): undefined reference to `fill_console_start_info'
Fixes: 4dd160583c79 ("x86/platform: introduce hypercall to get initial video console settings") Signed-off-by: Michal Orzel <michal.orzel@amd.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Avoid incorrectly triggering an error when a broadcast buffered ioreq
is not handled by all registered clients, as long as the failure is
strictly because the client doesn't handle buffered ioreqs.
Signed-off-by: Per Bilse <per.bilse@citrix.com> Reviewed-by: Paul Durrant <paul@xen.org>
Michal Orzel [Wed, 7 Dec 2022 11:16:49 +0000 (12:16 +0100)]
xen: remove trigraphs from comments
MISRA C rule 4.2 states that trigraphs (sequences of two question marks
followed by a specified third character [=/'()!<>-]) should not be used.
This applies to both code and comments. Thankfully, we do not use them
in the code, but still there are some comments where they are
accidentally used. Fix it.
With regards to the comments and respective macros in pci_regs.h, these
were inherited from Linux. Let's knowingly accept the divergence.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Jan Beulich [Wed, 7 Dec 2022 11:16:08 +0000 (12:16 +0100)]
x86/HVM: drop stale check from hvm_load_cpu_msrs()
Up until f61685a66903 ("x86: remove defunct init/load/save_msr()
hvm_funcs") the check of the _rsvd field served as an error check for
the earlier hvm_funcs.save_msr() invocation. With that invocation gone
the check makes no sense anymore: It is effectively dead code due to the
checking of the field in the earlier loop.
While dropping the conditional also eliminate the "err" local variable
(using a non-standard name anyway), replaced by suitable new/adjusted
"return" statements.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
libxl: arm: make creation of iommu node independent of disk device
The iommu node will be required for other virtio device types too, not
just disk device.
Move the call to make_xen_iommu_node(), out of the disk device specific
block and rename "iommu_created" variable to "iommu_needed", and set it
to true for virtio disk device.
make_virtio_mmio_node() creates the DT node for simple MMIO devices
currently, i.e. the ones that don't require any additional properties.
In order to allow using it for other complex device types, split the
functionality into two, one where the fdt node isn't closed and the
other one to create a simple DT node.
In order to prepare for adding support for more device types, create a
separate routine to allocate base and irq for a device as the same code
will be required for other device types too.
Also move updates to virtio_irq and virtio_enabled out of the disk
device specific block, as they will depend on other device types too.
projects / people / dwmw2 / xen.git / log