By initializing major_frame in a653sched_init(), an idle period was
inadvertently introduced into the default schedule. Account for the
initial value of major_frame when populating the default schedule.
Fixes: f2927d8343 ("xen/arinc653: fix delay in the start of major frame")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Since 4dbcb06536, the vGICv2 CPU interface is mapped in a deferred
manner. On domains with XEN_DOMCTL_CDF_trap_unmapped_accesses unset on
GICv2 hardware, the vGICv2 CPU interface fails to be mapped. A visible
symptom is that a domU gets stuck at:
[ 0.177983] smp: Bringing up secondary CPUs ...
Move the 2nd check_p2m earlier so it's prioritized over try_handle_mmio.
Fixes: 980aff4e8f ("xen/arm: Add way to disable traps on accesses to unmapped addresses")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
A hotplugged PCI device may be added uninitialized. In particular,
memory decoding might be disabled and the BARs might be zeroed. In this
case, the BARs will not be mapped in p2m. However, vpci_make_msix_hole()
unconditionally attempts to punch holes in p2m, leading to init_msix()
failing:
(XEN) d0v0 0000:01:00.0: existing mapping (mfn: 1c1880 type: 0) at 0 clobbers MSIX MMIO area
(XEN) d0 0000:01:00.0: init legacy cap 17 fail rc=-17, mask it
vpci_make_msix_hole() should only attempt to punch holes if the BARs
containing the MSI-X/PBA tables are mapped in p2m. Introduce a helper
for checking if a BAR is enabled, and add a check for the situation
inside vpci_make_msix_hole().
As a result of the newly introduced checks in vpci_make_msix_hole(),
move the call to vpci_make_msix_hole() within modify_decoding() to after
setting ->enabled.
Fixes: ee2eb6849d ("vpci: Refactor REGISTER_VPCI_INIT")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Scratch page quarantining is tied to specific IOMMU implementations, not
architectures, so tie it to AMD_IOMMU and INTEL_IOMMU instead of X86.
Fixes: dd7e55a884 ("iommu: restrict scratch page quarantining to x86")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
When attempting to xl pci-assignable-remove a PCI device, we encounter:
$ xl pci-assignable-remove 00:01.0
(XEN) SMMUv3: <no-node>: not attached to domain 32753
(XEN) d[IO]: deassign (0000:00:01.0) failed (-3)
libxl: error: libxl_pci.c:910:libxl__device_pci_assignable_remove: failed to de-quarantine 0000:00:01.0
When a PCI device is being deassigned from domIO,
arm_smmu_deassign_dev() should return before checking the smmu domain.
Fixes: 63919fc4d1 ("xen/arm: smmuv3: Add PCI devices support for SMMUv3")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
In arm_smmu_deassign_dev(), the return value from to_smmu_domain() is
NULL-checked. However, the implementation of to_smmu_domain() is a
container_of lookup, so the return value is unlikely to ever be NULL. In
case of a NULL argument to to_smmu_domain(), we will attempt to
dereference the non-NULL return value and encounter undefined behavior
and a crash:
$ xl pci-assignable-remove 00:01.0
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in drivers/passthrough/arm/smmu-v3.c:221:9
(XEN) applying non-zero offset ffffffffffffffc0 to null pointer
(XEN) Xen WARN at common/ubsan/ubsan.c:174
(XEN) ----[ Xen-4.21-unstable arm64 debug=y ubsan=y Tainted: C ]----
...
(XEN) Xen call trace:
(XEN) [<00000a0000350b2c>] ubsan.c#ubsan_epilogue+0x14/0xf0 (PC)
(XEN) [<00000a00003523e0>] __ubsan_handle_pointer_overflow+0x94/0x13c (LR)
(XEN) [<00000a00003523e0>] __ubsan_handle_pointer_overflow+0x94/0x13c
(XEN) [<00000a0000392f9c>] smmu-v3.c#to_smmu_domain+0x3c/0x40
(XEN) [<00000a000039e428>] smmu-v3.c#arm_smmu_deassign_dev+0x54/0x43c
(XEN) [<00000a00003a0300>] smmu-v3.c#arm_smmu_reassign_dev+0x74/0xc8
(XEN) [<00000a00003a7040>] pci.c#deassign_device+0x5fc/0xe0c
(XEN) [<00000a00003ade7c>] iommu_do_pci_domctl+0x7b4/0x90c
(XEN) [<00000a00003a34c0>] iommu_do_domctl+0x58/0xf4
(XEN) [<00000a00002ca66c>] do_domctl+0x2690/0x2a04
(XEN) [<00000a0000454d88>] traps.c#do_trap_hypercall+0xcf4/0x15b0
(XEN) [<00000a0000458588>] do_trap_guest_sync+0xa88/0xdd8
(XEN) [<00000a00003f8480>] entry.o#guest_sync_slowpath+0xa8/0xd8
(XEN)
(XEN) ================================================================================
(XEN) Data Abort Trap. Syndrome=0x4
(XEN) Walking Hypervisor VA 0xfffffffffffffff8 on CPU1 via TTBR 0x00000000406d0000
(XEN) 0TH[0x1ff] = 0x0
(XEN) CPU1: Unexpected Trap: Data Abort
(XEN) ----[ Xen-4.21-unstable arm64 debug=y ubsan=y Tainted: C ]----
...
(XEN) Xen call trace:
(XEN) [<00000a000039e494>] smmu-v3.c#arm_smmu_deassign_dev+0xc0/0x43c (PC)
(XEN) [<00000a000039e428>] smmu-v3.c#arm_smmu_deassign_dev+0x54/0x43c (LR)
(XEN) [<00000a00003a0300>] smmu-v3.c#arm_smmu_reassign_dev+0x74/0xc8
(XEN) [<00000a00003a7040>] pci.c#deassign_device+0x5fc/0xe0c
(XEN) [<00000a00003ade7c>] iommu_do_pci_domctl+0x7b4/0x90c
(XEN) [<00000a00003a34c0>] iommu_do_domctl+0x58/0xf4
(XEN) [<00000a00002ca66c>] do_domctl+0x2690/0x2a04
(XEN) [<00000a0000454d88>] traps.c#do_trap_hypercall+0xcf4/0x15b0
(XEN) [<00000a0000458588>] do_trap_guest_sync+0xa88/0xdd8
(XEN) [<00000a00003f8480>] entry.o#guest_sync_slowpath+0xa8/0xd8
Fix by changing to_smmu_domain() to return NULL in case of a NULL
argument.
Fixes: 452ddbe359 ("xen/arm: smmuv3: Add support for SMMUv3 driver")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
Enable the use of IOMMU + PCI in dom0 without having to specify
"pci-passthrough=yes". Due to possible platform specific dependencies
of the PCI host, we rely on dom0 to initialize it and perform
a PCI PHYSDEVOP calls to add each device to SMMU.
Because pci_passthrough is not always enabled on all architectures, add
a new function arch_pci_device_physdevop that checks if we need to enable
a subset of the PCI subsystem related to managing IOMMU configuration
for PCI devices.
Enable pci_init() for initializing Xen's internal PCI subsystem, and
allow PCI PHYSDEV ops when pci-passthrough is disabled.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
All IOMMU_QUARANTINE_* options are exposed on Arm since 163c6b5898
("xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option"). However,
only NONE and BASIC are implemented in any Arm iommu driver since
63919fc4d1 ("xen/arm: smmuv3: Add PCI devices support for SMMUv3") and
ca8f6ffeb6 ("xen/arm: smmuv2: Add PCI devices support for SMMUv2").
SCRATCH_PAGE is not yet implemented in any Arm iommu driver. Restrict
scratch page quarantining to x86 for now.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Since 622bdd9628 ("vpci/header: handle p2m range sets per BAR"), a
non-const pdev is no longer needed for error handling in
vpci_process_pending(). Const-ify pdev in vpci_process_pending(),
defer_map(), and struct vpci_vcpu.
Get rid of const-removal workaround in modify_bars().
Take the opportunity to remove an unused parameter in defer_map().
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Handle phantom functions in iommu_add_dt_pci_sideband_ids(). Each phantom
function will have a unique requestor ID (RID)/BDF. On ARM, we need to
map/translate the RID/BDF to an AXI stream ID for each phantom function
according to the pci-iommu device tree mapping [1]. The RID/BDF -> AXI stream ID
mapping in DT could allow phantom devices (i.e. devices with phantom functions)
to use different AXI stream IDs based on the (phantom) function.
[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/pci/pci-iommu.txt
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
When a device is passed through to a xl domU, the iomem ranges may
overlap with the extended regions. Remove iomem from extended regions.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Similarly to fba1b0974d, when a device is passed through to a
direct-map dom0less domU, the xen,reg ranges may overlap with the
extended regions. Remove xen,reg from direct-map domU extended regions.
Take the opportunity to update the comment ahead of find_memory_holes().
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
In file included from ./include/xen/pci.h:72,
from drivers/pci/pci.c:8:
./arch/arm/include/asm/pci.h:131:50: error: ‘struct rangeset’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
131 | static inline int pci_sanitize_bar_memory(struct rangeset *r)
| ^~~~~~~~
cc1: all warnings being treated as errors
Fixes: 4acab25a93 ("x86/vpci: fix handling of BAR overlaps with non-hole regions")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Code in domain-build.c and dom0less-build.c was migrated from init-only
files. Thus, they contain only __init functions. Enforce this at build
time.
Fixes: ad03faa942 ("xen/common: dom0less: make some parts of Arm's CONFIG_DOM0LESS common")
Fixes: d07b7369aa ("xen/common: dom0less: introduce common domain-build.c")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
All functions in dom0less-build.c should be __init.
Fixes: 2705f1adb9 ("xen: introduce Kconfig ARCH_PAGING_MEMPOOL")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
On Arm, we expect read handlers to have the bits above the access size
zeroed. vPCI read handlers may return all 1s. Mask off the bits above
the access size.
Fixes: 9a5e22b642 ("xen/arm: check read handler behavior")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
When a device is passed through to a dom0less domU, the xen,reg ranges
may overlap with the extended regions. Remove xen,reg from extended
regions.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
remove_shm_holes_for_domU() is unnecessarily complex: it re-creates the
extended regions from scratch.
Move the rangeset into find_domU_holes() and create the extended regions
only once. This makes is simpler to further manipulate the rangeset for
removing other regions.
Remove now-unused remove_shm_holes_for_domU().
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Erroneous logic was duplicated from add_ext_regions() into
add_hwdom_free_regions(). Frame numbers are converted to addresses, but
the end address (e) is rounded down to page size alignment. The logic to
calculate the size assumes e points to the last address, not page,
effectively leading to the region size being erroneously calculated to
be 2M smaller than the actual size of the region.
Fix by adding 1 to the frame number before converting back to address.
Fixes: 02975cc383 ("xen/arm: permit non direct-mapped Dom0 construction")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
In commit f37a598139, the arguments to add_ext_regions() were switched
from addresses to frame numbers. add_ext_regions() converts the frame
numbers back to addresses, but the end address (e) is rounded down to
page size alignment. The logic to calculate the size assumes e points to
the last address, not page, effectively leading to the region size being
erroneously calculated to be 2M smaller than the actual size of the
region.
Fix by adding 1 to the frame number before converting back to address.
Fixes: f37a598139 ("xen/arm: domain_build: Track unallocated pages using the frame number")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
We expect mmio read handlers to leave the bits above the access size
zeroed. Add an ASSERT to check this aspect of read handler behavior.
Suggested-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Introduce vmsix_table_host_{addr,base} returning the host physical MSI-X
table address and base. Use them in update_entry() and get_table().
Remove stale comment.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
The following sequence of events may lead a debug build of Xen to crash
when using the null scheduler:
1. domain creation (e.g. d1) failed due to bad configuration
2. complete_domain_destroy() was deferred
3. domain creation (e.g. d2) succeeds
At this point, d2 is running, while the zombie d1 is not fully cleaned
up:
(XEN) Online Cpus: 0-3
(XEN) Cpupool 0:
(XEN) Cpus: 0-3
(XEN) Scheduling granularity: cpu, 1 CPU per sched-resource
(XEN) Scheduler: null Scheduler (null)
(XEN) cpus_free = 3
(XEN) Domain info:
(XEN) Domain: 0
(XEN) 1: [0.0] pcpu=0
(XEN) 2: [0.1] pcpu=1
(XEN) Domain: 1
(XEN) 3: [1.0] pcpu=2
(XEN) Domain: 2
(XEN) 4: [2.0] pcpu=2
4. complete_domain_destroy() gets called for d1 and triggers the
following:
(XEN) Xen call trace:
(XEN) [<00000a0000322ed4>] null.c#unit_deassign+0x2d8/0xb70 (PC)
(XEN) [<00000a000032457c>] null.c#null_unit_remove+0x670/0xba8 (LR)
(XEN) [<00000a000032457c>] null.c#null_unit_remove+0x670/0xba8
(XEN) [<00000a0000336404>] sched_destroy_vcpu+0x354/0x8fc
(XEN) [<00000a0000227324>] domain.c#complete_domain_destroy+0x11c/0x49c
(XEN) [<00000a000029fbd0>] rcupdate.c#rcu_do_batch+0x94/0x3d0
(XEN) [<00000a00002a10c0>] rcupdate.c#__rcu_process_callbacks+0x160/0x5f4
(XEN) [<00000a00002a1e60>] rcupdate.c#rcu_process_callbacks+0xcc/0x1b0
(XEN) [<00000a00002a3460>] softirq.c#__do_softirq+0x1f4/0x3d8
(XEN) [<00000a00002a37c4>] do_softirq+0x14/0x1c
(XEN) [<00000a0000465260>] traps.c#check_for_pcpu_work+0x30/0xb8
(XEN) [<00000a000046bb08>] leave_hypervisor_to_guest+0x28/0x198
(XEN) [<00000a0000409c84>] entry.o#guest_sync_slowpath+0xac/0xd8
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Assertion 'npc->unit == unit' failed at common/sched/null.c:383
(XEN) ****************************************
Fix by skipping unit_deassign() when the unit to be removed does not
match the pcpu's currently assigned unit.
Fixes: c2eae2614c ("sched/null: avoid crash after failed domU creation")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Clang 16 reports:
In file included from arch/arm/tee/ffa.c:72:
arch/arm/tee/ffa_private.h:329:17: error: 'used' attribute ignored on a non-definition declaration [-Werror,-Wignored-attributes]
extern uint32_t __ro_after_init ffa_fw_version;
^
The variable ffa_fw_version is only used in ffa.c. Remove the
declaration in the header and make the definition in ffa.c static.
Fixes: 2f9f240a5e ("xen/arm: ffa: Fine granular call support")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
The hardware domain is expected to add a PF first before adding
associated VFs. If adding happens out of order, print a warning and
return an error. Drop the recursive call to pci_add_device().
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In commit 4f78438b45 ("vpci: use per-domain PCI lock to protect vpci
structure") a lock was moved from allocate_and_map_msi_pirq() to the
caller and changed from pcidevs_lock() to read_lock(&d->pci_lock).
However, one call path wasn't updated to reflect the change, leading to
a failed assertion observed under the following conditions:
* PV dom0
* Debug build (CONFIG_DEBUG=y) of Xen
* There is an SR-IOV device in the system with one or more VFs enabled
* Dom0 has loaded the driver for the VF and enabled MSI-X
(XEN) Assertion 'd || pcidevs_locked()' failed at drivers/passthrough/pci.c:535
(XEN) ----[ Xen-4.20-unstable x86_64 debug=y Not tainted ]----
...
(XEN) Xen call trace:
(XEN) [<ffff82d040284da8>] R pci_get_pdev+0x4c/0xab
(XEN) [<ffff82d040344f5c>] F arch/x86/msi.c#read_pci_mem_bar+0x58/0x272
(XEN) [<ffff82d04034530e>] F arch/x86/msi.c#msix_capability_init+0x198/0x755
(XEN) [<ffff82d040345dad>] F arch/x86/msi.c#__pci_enable_msix+0x82/0xe8
(XEN) [<ffff82d0403463e5>] F pci_enable_msi+0x3f/0x78
(XEN) [<ffff82d04034be2b>] F map_domain_pirq+0x2a4/0x6dc
(XEN) [<ffff82d04034d4d5>] F allocate_and_map_msi_pirq+0x103/0x262
(XEN) [<ffff82d04035da5d>] F physdev_map_pirq+0x210/0x259
(XEN) [<ffff82d04035e798>] F do_physdev_op+0x9c3/0x1454
(XEN) [<ffff82d040329475>] F pv_hypercall+0x5ac/0x6af
(XEN) [<ffff82d0402012d3>] F lstar_enter+0x143/0x150
In read_pci_mem_bar(), the VF obtains the struct pci_dev pointer for its
associated PF to access the vf_rlen array. This array is initialized in
pci_add_device() and is only populated in the associated PF's struct
pci_dev.
Access the vf_rlen array via the link to the PF, and remove the
troublesome call to pci_get_pdev().
Fixes: 4f78438b45 ("vpci: use per-domain PCI lock to protect vpci structure")
Reported-by: Teddy Astie <teddy.astie@vates.tech>
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Add links between a VF's struct pci_dev and its associated PF struct
pci_dev.
The hardware domain is expected to remove the associated VFs before
removing the PF. If removal happens out of order, print a warning and
return an error. This means that VFs can only exist with an associated
PF.
Additionally, if the hardware domain attempts to remove a PF with VFs
still present, mark the PF and VFs broken, because Linux Dom0 has been
observed to not respect the error returned.
Move the calls to pci_get_pdev() and pci_add_device() down to avoid
dropping and re-acquiring the pcidevs_lock().
Check !pdev->pf_pdev before adding the VF to the list to guard against
adding it multiple times.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Dom0 normally informs Xen of PCI device removal via
PHYSDEVOP_pci_device_remove, e.g. in response to SR-IOV disable or
hot-unplug. We might find ourselves with stale pdevs if a buggy dom0
fails to report removal via PHYSDEVOP_pci_device_remove. In this case,
attempts to access the config space of the stale pdevs would be invalid
and return all 1s.
Some possible conditions leading to this are:
1. Dom0 disables SR-IOV without reporting VF removal to Xen.
The Linux SR-IOV subsystem normally reports VF removal when a PF driver
disables SR-IOV. In case of a buggy dom0 SR-IOV subsystem, SR-IOV could
become disabled with stale dangling VF pdevs in both dom0 Linux and Xen.
2. Dom0 reporting PF removal without reporting VF removal.
During SR-IOV PF removal (hot-unplug), a buggy PF driver may fail to
disable SR-IOV, thus failing to remove the VFs, leaving stale dangling
VFs behind in both Xen and Linux. At least Linux warns in this case:
[ 100.000000] 0000:01:00.0: driver left SR-IOV enabled after remove
In either case, Xen is left with stale VF pdevs, risking invalid PCI
config space accesses.
When Xen is built with CONFIG_DEBUG=y, the following Xen crashes were
observed when dom0 attempted to access the config space of a stale VF:
(XEN) Assertion 'pos' failed at arch/x86/msi.c:1274
(XEN) ----[ Xen-4.20-unstable x86_64 debug=y Tainted: C ]----
...
(XEN) Xen call trace:
(XEN) [<ffff82d040346834>] R pci_msi_conf_write_intercept+0xa2/0x1de
(XEN) [<ffff82d04035d6b4>] F pci_conf_write_intercept+0x68/0x78
(XEN) [<ffff82d0403264e5>] F arch/x86/pv/emul-priv-op.c#pci_cfg_ok+0xa0/0x114
(XEN) [<ffff82d04032660e>] F arch/x86/pv/emul-priv-op.c#guest_io_write+0xb5/0x1c8
(XEN) [<ffff82d0403267bb>] F arch/x86/pv/emul-priv-op.c#write_io+0x9a/0xe0
(XEN) [<ffff82d04037c77a>] F x86_emulate+0x100e5/0x25f1e
(XEN) [<ffff82d0403941a8>] F x86_emulate_wrapper+0x29/0x64
(XEN) [<ffff82d04032802b>] F pv_emulate_privileged_op+0x12e/0x217
(XEN) [<ffff82d040369f12>] F do_general_protection+0xc2/0x1b8
(XEN) [<ffff82d040201aa7>] F x86_64/entry.S#handle_exception_saved+0x2b/0x8c
(XEN) Assertion 'pos' failed at arch/x86/msi.c:1246
(XEN) ----[ Xen-4.20-unstable x86_64 debug=y Tainted: C ]----
...
(XEN) Xen call trace:
(XEN) [<ffff82d040346b0a>] R pci_reset_msix_state+0x47/0x50
(XEN) [<ffff82d040287eec>] F pdev_msix_assign+0x19/0x35
(XEN) [<ffff82d040286184>] F drivers/passthrough/pci.c#assign_device+0x181/0x471
(XEN) [<ffff82d040287c36>] F iommu_do_pci_domctl+0x248/0x2ec
(XEN) [<ffff82d040284e1f>] F iommu_do_domctl+0x26/0x44
(XEN) [<ffff82d0402483b8>] F do_domctl+0x8c1/0x1660
(XEN) [<ffff82d04032977e>] F pv_hypercall+0x5ce/0x6af
(XEN) [<ffff82d0402012d3>] F lstar_enter+0x143/0x150
These ASSERTs triggered because the MSI-X capability position can't be
found for a stale pdev.
Latch the capability positions of MSI and MSI-X during device init, and
replace instances of pci_find_cap_offset(..., PCI_CAP_ID_MSI{,X}) with
the stored value. Introduce one additional ASSERT, while the two
existing ASSERTs in question continue to work as intended, even with a
stale pdev.
Fixes: 484d7c852e ("x86/MSI-X: track host and guest mask-all requests separately")
Fixes: 575e18d54d ("pci: clear {host/guest}_maskall field on assign")
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>
If a partial DT has a /gic node, but no references to it, dtc may omit
the phandle property. With the phandle property missing,
fdt_get_phandle() returns 0, leading Xen to generate a malformed domU
dtb due to invalid interrupt-parent phandle references. 0 is an invalid
phandle value. Add a zero check, and fall back to GUEST_PHANDLE_GIC.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
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