Non-PCI platform devices may use the ITS. Dom0 Linux drivers for such
devices are failing to register IRQs due to a missing #msi-cells
property. Add the missing #msi-cells property.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Rahul Singh <rahul.singh@arm.com>
When building with gcc with -finstrument-functions, optimization level
-O1, CONFIG_HYPFS=y and # CONFIG_HAS_SCHED_GRANULARITY is not set, the
the following build warning (error) is encountered:
common/sched/cpupool.c: In function ‘cpupool_gran_write’:
common/sched/cpupool.c:1220:26: error: ‘gran’ may be used uninitialized [-Werror=maybe-uninitialized]
1220 | 0 : cpupool_check_granularity(gran);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
common/sched/cpupool.c:1207:21: note: ‘gran’ declared here
1207 | enum sched_gran gran;
| ^~~~
This is a false positive. Silence the warning (error) by initializing
the variable.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
The ->profile member is at different offsets in struct rspinlock and
struct spinlock. When initializing the profiling bits of an rspinlock,
an unrelated member in struct rspinlock was being overwritten, leading
to mild havoc. Use the correct pointer.
Fixes: b053075d1a ("xen/spinlock: make struct lock_profile rspinlock_t aware")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
If rangeset_new() fails, err would not be set to an appropriate error
code. Set it to -ENOMEM.
Fixes: 580c458699 ("xen/domain: Call arch_domain_create() as early as possible in domain_create()")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Currently, Xen vPCI only supports virtualizing the MSI and MSI-X capabilities.
Hide all other PCI capabilities (including extended capabilities) from domUs for
now, even though there may be certain devices/drivers that depend on being able
to discover certain capabilities.
We parse the physical PCI capabilities linked list and add vPCI register
handlers for the next elements, inserting our own next value, thus presenting a
modified linked list to the domU.
Introduce helper functions vpci_hw_read8 and vpci_read_val. The vpci_read_val
helper function returns a fixed value, which may be used for read as zero
registers, or registers whose value doesn't change.
Introduce pci_find_next_cap_ttl() helper while adapting the logic from
pci_find_next_cap() to suit our needs, and implement the existing
pci_find_next_cap() in terms of the new helper.
Rename init_bars() to init_header() since it is now doing more than initializing
BARs.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Introduce a handler for the PCI status register, with ability to mask
the capabilities bit. The status register contains RsvdZ bits,
read-only bits, and write-1-to-clear bits. Additionally, we use RsvdP to
mask the capabilities bit. Introduce bitmasks to handle these in vPCI.
If a bit in the bitmask is set, then the special meaning applies:
ro_mask: read normal, guest write ignore (preserve on write to hardware)
rw1c_mask: read normal, write 1 to clear
rsvdp_mask: read as zero, guest write ignore (preserve on write to hardware)
rsvdz_mask: read as zero, guest write ignore (write zero to hardware)
The RO/RW1C/RsvdP/RsvdZ naming and definitions were borrowed from the
PCI Express Base 6.1 specification. RsvdP/RsvdZ bits help Xen enforce
our view of the world. Xen preserves the value of read-only bits on
write to hardware, discarding the guests write value. This is done in
case hardware wrongly implements R/O bits as R/W.
The mask_cap_list flag will be set in a follow-on change.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
GICD_CTL_ENABLE is a GICv2 bit. Remove it. The definitions of
GICD_CTL_ENABLE and GICD_CTLR_ENABLE_G1 are identical, so the value
written is unchanged.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Use pdev->sbdf instead of the PCI_SBDF macro in calls to pci_* functions
where appropriate. Move NULL check earlier.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Convert pci_find_*cap* functions and call sites to pci_sbdf_t, and remove some
now unused local variables. Also change to more appropriate types on lines that
are already being modified as a result of the pci_sbdf_t conversion.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Interrupt status introduced in PCI 2.3
Immediate readiness introduced in PCIe 4.0
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
These were left over after a previous pci_sbdf_t conversion.
Fixes: 0c38c61aad ("pci: switch pci_conf_write32 to use pci_sbdf_t")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Make the paramater names of the prototype match the definition. No functional
change.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
When mapping BARs for vPCI, it's valid for a BAR mfn_t start to equal the BAR
mfn_t end (i.e. start == end) since end is inclusive. However, pci_check_bar()
currently returns false in this case, which results in Xen not mapping the BAR
in the guest 2nd stage page tables. In this example boot log, Linux has mapped
the BARs in the 1st stage, but since Xen did not map them in the 2nd stage,
Linux encounters a data abort and panics:
[ 2.593300] pci 0000:00:00.0: BAR 0: assigned [mem 0x50008000-0x50008fff]
[ 2.593682] pci 0000:00:00.0: BAR 2: assigned [mem 0x50009000-0x50009fff]
[ 2.594066] pci 0000:00:00.0: BAR 4: assigned [mem 0x5000a000-0x5000afff]
...
[ 2.810502] virtio-pci 0000:00:00.0: enabling device (0000 -> 0002)
(XEN) 0000:00:00.0: not mapping BAR [50008, 50008] invalid position
(XEN) 0000:00:00.0: not mapping BAR [50009, 50009] invalid position
(XEN) 0000:00:00.0: not mapping BAR [5000a, 5000a] invalid position
[ 2.817502] virtio-pci 0000:00:00.0: virtio_pci: leaving for legacy driver
[ 2.817853] virtio-pci 0000:00:00.0: enabling bus mastering
(XEN) arch/arm/traps.c:1992:d0v0 HSR=0x00000093010045 pc=0xffff8000089507d4 gva=0xffff80000c46d012 gpa=0x00000050008012
[ 2.818397] Unable to handle kernel ttbr address size fault at virtual address ffff80000c46d012
...
Adjust the end physical address e to account for the full page when converting
from mfn, at which point s and e cannot be equal, so drop the equality check in
the condition.
Note that adjusting e to account for the full page also increases the accuracy
of the subsequent is_bar_valid check.
Fixes: cc80e2bab0 ("xen/pci: replace call to is_memory_hole to pci_check_bar")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Rahul Singh <rahul.singh@arm.com>
Tested-by: Rahul Singh <rahul.singh@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
clang doesn't like extern with __attribute__((__used__)):
./arch/arm/include/asm/setup.h:171:8: error: 'used' attribute ignored [-Werror,-Wignored-attributes]
extern DEFINE_BOOT_PAGE_TABLE(boot_pgtable);
^
./arch/arm/include/asm/lpae.h:273:29: note: expanded from macro 'DEFINE_BOOT_PAGE_TABLE'
lpae_t __aligned(PAGE_SIZE) __section(".data.page_aligned") \
^
./include/xen/compiler.h:71:27: note: expanded from macro '__section'
#define __section(s) __used __attribute__((__section__(s)))
^
./include/xen/compiler.h:104:39: note: expanded from macro '__used'
#define __used __attribute__((__used__))
^
Simplify the declarations by getting rid of the macro (and thus the
__aligned/__section/__used attributes) in the header. No functional change
intended as the macro/attributes are present in the respective definitions in
xen/arch/arm/mm.c.
Fixes: 1c78d76b67 ("xen/arm64: mm: Introduce helpers to prepare/enable/disable the identity mapping")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
When creating a domU, but the creation fails, there is a corner case that may
lead to a crash in the null scheduler when running a debug build of Xen.
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Assertion 'npc->unit == unit' failed at common/sched/null.c:379
(XEN) ****************************************
The events leading to the crash are:
* null_unit_insert() was invoked with the unit offline. Since the unit was
offline, unit_assign() was not called, and null_unit_insert() returned.
* Later during domain creation, the unit was onlined
* Eventually, domain creation failed due to bad configuration
* null_unit_remove() was invoked with the unit still online. Since the unit was
online, it called unit_deassign() and triggered an ASSERT.
To fix this, only call unit_deassign() when npc->unit is non-NULL in
null_unit_remove.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Dario Faggioli <dfaggioli@suse.com>
When building with EXTRA_CFLAGS_XEN_CORE="-Wtype-limits", we observe the
following warning:
arch/arm/pci/pci-host-common.c: In function ‘pci_host_common_probe’:
arch/arm/pci/pci-host-common.c:238:26: warning: comparison is always false due to limited range of data type [-Wtype-limits]
238 | if ( bridge->segment < 0 )
| ^
This is due to bridge->segment being an unsigned type. Fix it by introducing a
new variable of signed type to use in the condition.
Fixes: 6ec9176d94 ("xen/arm: PCI host bridge discovery within XEN on ARM")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Rahul Singh <rahul.singh@arm.com<mailto:rahul.singh@arm.com>>
When building the hypervisor with -Og and GCC 11/12, we encounter the
following error:
arch/arm/domain_build.c: In function ‘make_cpus_node’:
arch/arm/domain_build.c:2040:12: error: ‘clock_valid’ may be used uninitialized [-Werror=maybe-uninitialized]
2040 | if ( clock_valid )
| ^
arch/arm/domain_build.c:1947:10: note: ‘clock_valid’ was declared here
1947 | bool clock_valid;
| ^~~~~~~~~~~
cc1: all warnings being treated as errors
Fix it by initializing the variable.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
When building the hypervisor with -Og, we run into a __bad_cmpxchg link error:
aarch64-none-linux-gnu-ld: prelink.o: in function `__int_cmpxchg':
.../xen/./arch/arm/include/asm/arm64/cmpxchg.h:117: undefined reference to `__bad_cmpxchg'
aarch64-none-linux-gnu-ld: .../xen/./arch/arm/include/asm/arm64/cmpxchg.h:117: undefined reference to `__bad_cmpxchg'
aarch64-none-linux-gnu-ld: ./.xen-syms.0: hidden symbol `__bad_cmpxchg' isn't defined
aarch64-none-linux-gnu-ld: final link failed: bad value
This is due to the function __guest_cmpxchg not being inlined in the -Og build
with gcc 12. Fix this by marking __guest_cmpxchg always_inline.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
When building the hypervisor for arm64 with -Og, we encounter a (false)
uninitialized use warning:
arch/arm/efi/boot.c: In function ‘efi_start’:
arch/arm/efi/boot.c:1468:9: error: ‘argc’ may be used uninitialized [-Werror=maybe-uninitialized]
1468 | efi_arch_handle_cmdline(argc ? *argv : NULL, options, name.s);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/arm/efi/boot.c:1263:21: note: ‘argc’ was declared here
1263 | unsigned int i, argc;
| ^~~~
cc1: all warnings being treated as errors
Fix this by initializing argc. As a precaution, also initialize argv.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
When building with clang 12 and CONFIG_ARM_SMMU_V3=y, we observe the
following build error:
drivers/passthrough/arm/smmu-v3.c:1408:20: error: unused function 'arm_smmu_disable_pasid' [-Werror,-Wunused-function]
static inline void arm_smmu_disable_pasid(struct arm_smmu_master *master) { }
^
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>
All functions in domain_build.c should be marked __init. This was
spotted when building the hypervisor with -Og.
Fixes: 1050a7b91c ("xen/arm: add pci-domain for disabled devices")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Stewart Hildebrand