xen/arm: p2m: Correctly initialize cur_offset

{~0,} only initializes the first cell of the array to ~0. The other cells
are initialized to 0.

Explicitly initialize every cells of the array and, at the same time, do the
same for the mappings.

This is fixing boot after 82985d7 "xen: arm: handle variable p2m levels
in apply_p2m_changes" on platform where the root-level doesn't have
concatenate table (such as the Foundation Model).

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
libxc: fix mmap leak in xc_unmap_domain_meminfo/xc_map_domain_meminfo

xc_unmap_domain_meminfo uses P2M_FLL_ENTRIES macro instead of P2M_FL_ENTRIES.
Moreover, P2M_FL_ENTRIES macro uses (dinfo->p2m_size) which is always 0 here
as we don't initialize it. The result is that we always unmap just 1 frame.

xc_map_domain_meminfo uses P2M_FLL_ENTRIES macro instead of P2M_FL_ENTRIES
on failure path.

The issue went unnoticed mostly because we use unmap_domain_meminfo and
xc_map_domain_meminfo in one-shot xen-mfndump and xen-hptool (through
xc_exchange_page()) tools. When used is long-running apps (e.g. in xl)
domains become zombies after their death.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
EFI: update documentation for arm64

The arm64 EFI boot support added a new 'dtb' value to the configuration file.
Update the documentation to describe this and how the coniguration file is not
used when GRUB loads the modules. Updates 'ucode' description to indicate that
it is x86 only.

Signed-off-by: Roy Franz <roy.franz@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
arm64: create xen.efi binary for arm64

The 'xen' binary for arm64 is both an Image file and a PE/COFF executable,
copy it to xen.efi so that the 'make install' processing is shared with
x86. Prior to this 'make install' was broken on arm64.

Signed-off-by: Roy Franz <roy.franz@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
x86/APIC: don't make wrong implications on constants

For the physical APIC, oprofile code was abusing APIC_DM_NMI as a mask.

For the virtual APIC, a wrong assumption was made that LVTPC could be
programmed to only fixed or NMI delivery modes. While other modes are
invalid here, we still shouldn't inject an NMI into the guest in such
a case. Instead just do nothing.

In the course of adjusting this it became obvious that what value
vpmu_do_interrupt() returns on its various return paths was pretty
arbitrary. With its only caller ignoring the return value, simply make
the function's return type "void".

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
xen/arm: Broadcom 7445D0 ARM cpu support.

Relax cpu id mask to cover minor cpu revisions in the SoC versions.

Signed-off-by: Jon Fraser <jfraser@broadcom.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
xen/arm: Update early print console UART address for Broadcom 7445D0.

The console UART address changed between chip versions C0 and D0.
Broadcom 7445[ABC]0 versions were not released and are not supported.

Signed-off-by: Jon Fraser <jfraser@broadcom.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
xen/arm: Add support for Broadcom 7445D0 A15 platform.

This code supports the Broadcom 7445D0 32-bit A15 based platform.

Signed-off-by: Jon Fraser <jfraser@broadcom.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen/arm/docs: Document Broadcom 7445D0 early printk support

Use CONFIG_EARLY_PRINTK=brcm for Broadcom 7445D0 based boards.

Signed-off-by: Jon Fraser <jfraser@broadcom.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen/arm: add support for early printk for HiSilicon D01 platform

This platform use a standard 8250 device on port 0xe4007000.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
gicv2: Add compatibility id for gic-400

Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
amd/seattle: Add early printk message for the platform

Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen/arm: Fix crash if last memory section is bigger than 1gb

On arm32 the xenheap has a maximum size of 1GB. On systems with more than 8GB
(so 1/8 total RAM is greater than 1GB) there is no point in searching for a
region with 1/8 of the total RAM when only 1GB will be used. Therefore limit
the maximum size to 1GB before searching.

Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- updated commit message as discussed ]
amd/seattle: Initial revision of AMD Seattle support

This patch add initial (minimal) platform support for AMD Seattle,
which mainly just define the matching ID, and specify system_off,
and system_reset mechanism.

Initially, the firmware only support a subset of PSCI-0.2 functions,
system-off and system-reset. The mechanism for bring up auxiliary processors
is still using spin-table.

Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
x86/MSI: fix MSI-X case of freeing IRQ

Commit d1b6d0a024 ("x86: enable multi-vector MSI") went a little too
far with moving things around in msi_free_irqs() in order to streamline
the code: We shouldn't drop the MSI-X control page reference before
calling destroy_irq(), as the latter will call us back via
desc->handler->shutdown() (effectively invoking to msi_set_mask_bit()).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86: restore reserving of IO-APIC pages in XENMEM_machine_memory_map output

Commit d1222afda4 ("x86: allow Dom0 read-only access to IO-APICs") had
an unintended side effect: By no longer adding IO-APIC pages to Dom0's
iomem_caps these also no longer get reported as reserved in the machine
memory map presented to it (which got added there intentionally by
commit b8a456caed ["x86: improve reporting through
XENMEM_machine_memory_map"] because many BIOSes fail to add these).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
don't allow Dom0 access to IOMMUs' MMIO pages

Just like for LAPIC, IO-APIC, MSI, and HT we shouldn't be granting Dom0
access to these. This implicitly results in these pages also getting
marked reserved in the machine memory map Dom0 uses to determine the
ranges where PCI devices can have their MMIO ranges placed.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
x86: favor function parameter over global in construct_dom0()

There's no reason to use the "hardware_domain" variable anywhere here,
making the code more cumbersome to read.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
AMD/guest_iommu: properly disable guest iommu support

AMD Guest IOMMU support was added to allow correct use of PASID and PRI
hardware support with an ATS-aware guest driver.

However, support cannot possibly function as guest_iommu_set_base() has no
callers.  This means that its MMIO region's P2M pages are not set to
p2m_mmio_dm, preventing any invocation of the MMIO read/write handlers.

c/s fd186384 "x86/HVM: extend LAPIC shortcuts around P2M lookups" introduces a
path (via hvm_mmio_internal()) where iommu_mmio_handler claims its MMIO range,
and causes __hvm_copy() to fail with HVMCOPY_bad_gfn_to_mfn.

iommu->mmio_base defaults to 0, with a range of 8 pages, and is unilaterally
enabled in any HVM guests when the host IOMMU(s) supports any extended
features.

Unfortunately, HVMLoader's AP boot trampoline executes an `lmsw` instruction
at linear address 0x100c which unconditionally requires emulation.  The
instruction fetch in turn fails as __hvm_copy() fails with
HVMCOPY_bad_gfn_to_mfn.

The result is that multi-vcpu HVM guests do not work on newer AMD hardware, if
IOMMU support is enabled in the BIOS.

Change the default mmio_base address to ~0ULL.  This prevents
guest_iommu_mmio_range() from actually claiming any physical range
whatsoever, which allows the emulation of `lmsw` to succeed.

Reported-by: Roberto Luongo <rluongo@ready.it>
Suggested-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Roberto Luongo <rluongo@ready.it>
Acked-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
docs, amd_ucode: add AMD container file format notes

This patch introduces documentation notes about AMD container
file formats and where to obtain latest container files from.

Also, We provide a how-to for updating patch level by
concatenating container files along with initrd images.
Misc notes about how Xen handles two containers of same
kind (if/when) they are concatenated together are also included.

Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>