"THE REST" maintainers should always be CCed for any modification that
don't fall under the responsability of a specific component maintainer.
However, the script get_maintainers.pl will remove "THE REST"
maintainers as soon as one maintainer of a specific component will be
present.
Fix the script once for all.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
We are phasing out the use of bool_t in the hypervisor code.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This is improving the code readability and avoid to dereference the
table every single time we need to access the entry.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This newly introduced lpae_valid and lpae_table helpers will recude the
code and make more readable.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
lpae_* helpers can work on any LPAE translation tables. Move them in
lpae.h to allow other part of Xen to use them.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The helpers p2m_valid, p2m_table, p2m_mapping and p2m_is_superpage are
not specific to the stage-2 translation tables. They can also work on
any LPAE translation tables. So rename then to lpae_* and use pte.walk
to look for the value of the field.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
page.h is getting bigger. Move out every LPAE definitions in a separate
header. There is no functional changes.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Add a bit more safety when using create_xen_entries.
Also when destroying/modifying mapping, the MFN is currently not used.
Rather than passing _mfn(0) use INVALID_MFN to stay consistent with the
other usage.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The file xen/arch/arm/livepatch.c is using typesafe MFN in most of
the place. The only caller to virt_to_mfn is using with _mfn(...).
To avoid extra _mfn(...), re-define virt_to_mfn within
xen/arch/arm/livepatch.c to handle typesafe MFN.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel..org>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
The file xen/arch/arm/alternative.c is using typesafe MFN in most of
the place. The only caller to virt_to_mfn is using with _mfn(...).
To avoid extra _mfn(...), re-define virt_to_mfn within
xen/arch/arm/alternative.c to handle typesafe MFN.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabelllini <sstabellini@kernel.org>
The file xen/arch/arm/domain_build.c is using typesafe MFN in most of
the place. The only caller to virt_to_mfn is using prefixed with
_mfn(...).
To avoid extra _mfn(...), re-define virt_to_mfn within
arch/arm/domain_build.c to handle typesafe MFN.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The file xen/arch/arm/mm.c is using the typesafe MFN in most of the
place. This requires all caller of virt_to_mfn to prefixed by _mfn(...).
To avoid the extra _mfn(...), re-defined virt_to_mfn within arch/arm/mm.c
to handle typesafe MFN.
This patch also introduce __virt_to_mfn, so virt_to_mfn can be
re-defined easily.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The file xen/arch/arm/p2m.c is using typesafe MFN in most of the place.
This requires caller to mfn_to_page and page_to_mfn to use _mfn/mfn_x.
To avoid extra _mfn/mfn_x, re-define mfn_to_page and page_to_mfn within
xen/arch/arm/p2m.c to handle typesafe MFN.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
xenheap_mfn_end is storing an MFN and not a physical address. The value will
be reset after the loop. So drop this bogus xenheap_mfn_end.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The current implementation of {G,M}FN_INVALID cannot be used to
initialize global variable because the initializer element is not a
constant.
Due to a bug in GCC 4.9 and older ([1]), it is not easy to find a common
value to initialize a variable and directly passed as an argument.
Introduce 2 news define {G,M}FN_INVALID_INITIALIZER to be used for
initializing a variable.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64856
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Tim Deegan <tim@xen.org>
INVALID_{G,M}FN are defined using static inline helpers _{g,m}fn.
This means, they cannot be used to initialize a build time static variable:
In file included from mm.c:24:0:
xen/xen/include/xen/mm.h:59:26: error: initializer element is not constant
#define INVALID_MFN _mfn(~0UL)
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Tim Deegan <tim@xen.org>
[jb: add parentheses and const]
Acked-by: Jan Beulich <jbeulich@suse.com>
The current function vgic_to_sgi does not sanitize the target mask and
may therefore get an invalid vCPU ID. This will result to an out of
bound access of d->vcpu[...] as there is no check whether the vCPU ID is
within the maximum supported by the guest.
This was introduced by commit ea37fd2111 "xen/arm: split vgic driver
into generic and vgic-v2 driver".
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
gic_raise_inflight_irq will be called if the IRQ is already inflight
(i.e the IRQ is injected to the guest). If the IRQ is already already in
the LRs, then the associated LR will be updated.
To know if the interrupt is already in the LR, the function check if the
interrupt is queued. However, if the interrupt is not enabled then the
interrupt may not be queued nor in the LR. So gic_update_one_lr may be
called (if we inject on the current vCPU) and read the LR.
Because the interrupt is not in the LR, Xen will either read:
* LR 0 if the interrupt was never injected before
* LR 255 (GIC_INVALID_LR) if the interrupt was injected once. This
is because gic_update_one_lr will reset p->lr.
Reading LR 0 will result to potentially update the wrong interrupt and
not keep the LRs in sync with Xen.
Reading LR 255 will result to:
* Crash Xen on GICv3 as the LR index is bigger than supported (see
gicv3_ich_read_lr).
* Read/write always GICH_LR + 255 * 4 that is not part of the memory
mapped.
The problem can be prevented by checking whether the interrupt is
enabled in gic_raise_inflight_irq before calling gic_update_one_lr.
A follow-up of this patch is expected to mitigate the issue in the
future.
This is XSA-223.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The new wrappers will add more safety when converting an address to a
frame number (either machine or guest). A follow-up patch will use them
to simplify the code.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
gfn_to_mfn is a wrapper of p2m_lookup which does not return the
p2m_type.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This is matching the x86 side where the __* version is used if you need
to override the helpers in source files.
At the same time, move the non-underscore version at the end of the
defintion and add a comment to explain them.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The physical address is computed from the machine frame number, so
checking if the physical address is page aligned is pointless.
Furthermore, directly assigned the MFN to the corresponding field in the
entry rather than converting to a physical address and orring the value.
It will avoid to rely on the field position and make the code clearer.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Fix the comment coding style and add a newline before the return.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The file mm.c is the only user of mfn_to_xen_entry. This will also help
to use the typesafe MFN.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Add a new helper clear_table to clear a page table entry and invalidate
the cache.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Both helpers access_ok and array_access_ok are not used on ARM. Remove
them.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The same set of functions is used to set as well as to clean P2M
entries, except for clean operations (INVALID_MFN ~0UL) is passed as a
parameter. Unfortunately, when calculating an appropriate target order
for a particular mapping INVALID_MFN is taken into account which leads
to 4K page target order being set each time even for 2MB and 1GB
mappings.
This will result to break down the superpage into 4K mappings and leave
empty tables allocated.
This was introduced by commit 2ef3e36ec7 "xen/arm: p2m: Introduce
p2m_set_entry and __p2m_set_entry".
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Currently we crash Xen if we see an ESR_EL2.EC value we don't recognise.
As configurable disables/enables are added to the architecture
(controlled by RES1/RESO bits respectively), with associated synchronous
exceptions, it may be possible for a guest to trigger exceptions with
classes that we don't recognise.
While we can't service these exceptions in a manner useful to the guest,
we can avoid bringing down the host. Per ARM DDI 0487A.k_iss10775, page
D7-1937, EC values within the range 0x00 - 0x2c are reserved for future
use with synchronous exceptions, and EC within the range 0x2d - 0x3f may
be used for either synchronous or asynchronous exceptions.
The patch makes Xen handle any unknown EC by injecting an UNDEFINED
exception into the guest, with a corresponding (ratelimited) warning in
the log.
This patch is based on Linux commit f050fe7a9164 "arm: KVM: Survive unknown
traps from the guest".
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The function do_trap_hypervisor is currently handling both trap coming
from the hypervisor and the guest. This makes difficult to get specific
behavior when a trap is coming from either the guest or the hypervisor.
Split the function into two parts:
- do_trap_guest_sync to handle guest traps
- do_trap_hyp_sync to handle hypervisor traps
On AArch32, the Hyp Trap Exception provides the standard mechanism for
trapping Guest OS functions to the hypervisor (see B1.14.1 in ARM DDI
0406C.c). It cannot be generated when generated when the processor is in
Hyp Mode, instead other exception will be used. So it is fine to replace
the call to do_trap_hypervisor by do_trap_guest_sync.
For AArch64, there are two distincts exception depending whether the
exception was taken from the current level (hypervisor) or lower level
(guest).
Note that the unknown traps from guests will lead to panic Xen. This is
already behavior and is left unchanged for simplicy. A follow-up patch
will address that.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Per Table B1-3 in ARM DDI 0406C.c, the vector 0x8 for hyp is called
"Hypervisor Call".
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Commit 2c77db77 "xen/arm: efi: Avoid duplicating the addition of a new
bank", introduced a new function meminfo_add_bank that add a new bank.
This new code fails to check correctly the size of the array which may
result to an out-of-bounds write.
Coverity-ID: 1433183
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
There is currently no sanity check on the FDT passed by the bootloader.
Whilst they are stricly not necessary, it will avoid us to spend hours
to try to find out why it does not work.
>From the booting documentation for AArch32 [1] and AArch64 [2] must :
- be placed on 8-byte boundary
- not exceed 2MB (only on AArch64)
Even if AArch32 does not seem to limit the size, Xen is not currently
able to support more the 2MB FDT. It is better to crash rather with a nice
error message than claiming we are supporting any size of FDT.
The checks are mostly borrowed from the Linux code (see fixmap_remap_fdt
in arch/arm64/mm/mmu.c).
[1] Section 2 in linux/Documentation/arm64/booting.txt
[2] Section 4b in linux/Documentation/arm/Booting
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The FDT will not be accessed before start_xen (begining of C code) is
called and it will be easier to maintain as the code could be common
between AArch32 and AArch64.
A new function early_fdt_map is introduced to map the FDT in the boot
page table.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This function will be called by other function later one. This will
avoid forward declaration and keep the new function close to sibling
ones.
This was moved just after *_fixmap helpers as they are page table
handling functions too.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The 2 new defines will help to avoid hardcoding the size and the end of
the slot in the code.
The newlines are added for clarity.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
When booting using ACPI, not all MMIOs can be discovered by parsing the
static tables or the UEFI memory map. A lot of them will be described in
the DSDT. However, Xen does not have an AML parser which requires us to
find a different approach.
During the first discussions on supporting ACPI (see design doc [1]), it
was decided to rely on the hardware domain to make a request to the
hypervisor to map the MMIO region in stage-2 page table before accessing
it. This approach works fine if the OS has limited hooks to modify the
page tables.
In the case of Linux kernel, notifiers have been added to map
the MMIO regions when adding a new AMBA/platform device. Whilst this is
covering most of the MMIOs, some of them (e.g OpRegion, ECAM...) are not
related to a specific device or the driver is not using the
AMBA/platform API. So more hooks would need to be added in the code.
Various approaches have been discussed (see [2]), one of them was to
create stage-2 mappings seamlessly in Xen upon hardware memory faults.
This approach was first ruled out because it relies on the hardware
domain to probe the region before any use. So this would not work when
DMA'ing to another device's MMIO region when the device is protected by
an SMMU. It has been pointed out that this is a limited use case compare
to DMA'ing between MMIO and RAM.
This patch implements this approach. All MMIOs region will be mapped in
stage-2 using p2m_mmio_direct_c (i.e normal memory outer and inner
write-back cacheable). The stage-1 page table will be in control of the
memory attribute. This is fine because the hardware domain is a trusted
domain.
Note that MMIO will only be mapped on a data abort fault. It is assumed
that it will not be possible to execute code from MMIO
(p2m_mmio_direct_c will forbid that).
As mentioned above, this solution will cover most of the cases. If a
platform requires to do DMA'ing to another device's MMIO region without
any access performed by the OS. Then it will be expected to have
specific platform code in the hypervisor to map the MMIO at boot time or
the OS to use the existing hypercalls (i.e XENMEM_add_to_add_physmap{,_batch})
before any access.
[1] https://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
[2] https://marc.info/?l=linux-arm-kernel&m=148469169210500&w=2
Signed-off-by: Julien Grall <julien.grall@arm.com>
Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The ARM architecture allows an OS to have per-CPU page tables, as it
guarantees that TLBs never migrate from one CPU to another.
This works fine until this is done in a guest. Consider the following
scenario:
- vcpu-0 maps P to V
- vpcu-1 maps P' to V
If run on the same physical CPU, vcpu-1 can hit in TLBs generated by
vcpu-0 accesses, and access the wrong physical page.
The solution to this is to keep a per-p2m map of which vCPU ran the last
on each given pCPU and invalidate local TLBs if two vPCUs from the same
VM run on the same CPU.
Unfortunately it is not possible to allocate per-cpu variable on the
fly. So for now the size of the array is NR_CPUS, this is fine because
we still have space in the structure domain. We may want to add an
helper to allocate per-cpu variable in the future.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Define INVALID_VCPU_ID as MAX_VIRT_CPUS to avoid casting problem later
on. At the moment it can always fit in uint8_t.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
hvm_domain only contains the HVM_PARAM that on ARM are not used often.
So it is not necessary to have hvm_domain fitting in a cacheline. Drop
it to save 128 bytes in the structure arch_domain.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Currently the acpi banks are stored in a separate variable and have an
header just for them.
This variable can be moved in the structure bootinfo removing an header
and a global variable.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The code contains a lot of memory_map[offset]. This could be simplified
by incrementing the descriptor pointer every time.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The code to add a new memory descriptor is duplicated three times. Add a
new helper that adds the descriptor.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The code to add a new bank is duplicated twice. Add a new helper that
checks if the maximum of bank has not reached and adds the bank.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The p2m code is using the page list field to link all the pages used
for the stage-2 page tables. The page is added into the p2m->pages
list just after the allocation but never removed from the list.
The page list field is also used by the allocator, not removing may
result a later Xen crash due to inconsistency (see [1]).
This bug was introduced by the reworking of p2m code in commit 2ef3e36ec7
"xen/arm: p2m: Introduce p2m_set_entry and __p2m_set_entry".
[1] https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00524.html
Reported-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Make it easier to figure out whether Xen is booting using ACPI or DT by
printing a message on the console.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
There are multiple path disable ACPI on error. Consolidate in a single
place, this will help in a follow-up patch to add more code on the error
path.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
When the GICv3 is not GICv2 compatible, the associated field in the MADT
will be zeroed. However, the rest of the code expects the variable to
be set to INVALID_PADDR.
This will result to false detection of GICv2 and give I/O access to page
0 for the hardware domain.
Thankfully, it will fail because the size of GICV has not been set.
Fix the detection by converting 0 to INVALID_PADDR for the GICC and
GICV base. At the same time only set the size of each region when the
base address is not 0.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Since commit 4557c22 "xen: arm: rewrite start of day page table and cpu
bring up", Xen requires to be launched in NS HYP/EL2.
xen.axf is generated in order to directly boot Xen on ARM models (e.g
Foundation). However they usually start in secure mode, which mean Xen
cannot boot.
The way forward to boot Xen on models is using either EFI or
bootwrapper [1].
[1] https://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The build option CONFIG_LOAD_ADDRESS is defined but never plumbed
through.
Signed-off-by: Julien Grall <julien.gralL@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Commit 146786b "efi: create efi_enabled()" introduced a variable
efi_flags stored in BSS and used to pass information between the stub
and Xen. However on ARM, BSS is zeroed after the stub has finished to
run and before Xen is started. This means that the bits set in efi_flags
will be lost.
We were not affected before because all the variables used to pass
information between Xen and the stub are living in initdata or data.
Looking at the description of the field SizeOfRawData in the PE/COFF
header (see [1]):
"If this is less than VirtualSize, the remainder of the section is
zero-filled. Because the SizeOfRawData field is rounded but the
VirtualSize field is not, it is possible for SizeOfRawData to be greater
than VirtualSize as well. When a section contains only uninitialized
data, this field should be zero."
Both VirtualSize and SizeOfRawData are correctly set in the header (see
arch/arm/arm64/head.S) so the EFI firmware will zero BSS for us.
Therefore we don't need to zero BSS before running the EFI stub and can
skip the one between the EFI stub and Xen.
To avoid another branch instruction, slightly refactor the code. The
register x26 is allocated to hold whether BSS is skipped. The value will
be:
- 0 when the code is running on CPU0 and EFI is not used
- 1 when EFI is used or running on other processor than the boot one.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
"The effects of reading ICC_IAR0_EL1 and ICC_IAR1_EL1 on the state of a
returned INTID are not guaranteed to be visible until after the execution
of a DSB".
Because of the GIC is an external component, a dsb sy is required.
Without it the sysreg read may not have been made visible on the
redistributor.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
iomem_deny_access is working on MFN and not GFN. Make it clear by
renaming the local variables.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This file contains data and code only used at initialization. Mark the
file as such in the build system and correct kind_guess.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
AArch32 guest will use co-processor registers to access the GICv3 (see
8.5 in IHI 0069C). Some of the registers have to be trapped and emulated
(e.g ICC_SGI1R), this is the purpose of this patch.
The rest of the emulation already supports access required for AArch32
so nothing has to be changed there.
Note this is only enabling 32-bit guest using GICv3 on Xen ARM64. Further
work would be required to compile GICv3 and vGICv3 for Xen ARM32.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The emulation of the co-processor register ICC_SGI1R is the same as the
system register ICC_SGI1R_EL1. So move the emulation outside and use the
newly introduced helper vreg_emulate_sysreg64 to abstract the access.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
We will want to emulate co-processor registers access in a follow-up
patch.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Factorize the code to emulate 32-bit and 64-bit access to a co-processor
in specific helpers.
The new helpers will be used in different components to simplify the
emulation.
Finally, the prototypes for the callbacks to emulate 32-bit and 64-bit
co-processor access are the same as the sysreg one. Rather than
introducing new ones, repurpose the existent prototypes.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The core emulation of sysreg (reading/writing registers) is not specific
to the virtual timer. Move the helpers in a new header vreg.h.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The vGICv3 depends whether Xen has a host driver for GICv3, not on the
architecture (AArch64 vs AArch32).
Note CONFIG_HAS_GICV3 is enabled only when for ARM64 build, so there is
no functional change.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Couple of clean-up for the vgic sysreg emulation:
- Reference the public documentation rather than a non-public one
- Let the vgic emulation decides whether a register needs to be
emulated
- Drop unnecessary debug printk. They don't bring much information
and can be misleading (vGICv2 does not support those registers)
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
emulate_sysreg callback can only return 2 values: 0 or 1. Use bool
instead to make clear only two possible values exist.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
vgic_v{2,3}_to_sgi.
vgic_*to_sgi functions can only return 2 values: 0 or 1. Use bool instead
to make clear only two possible values exist.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Since commit 9202342 "xen/build: Use C99 booleans", bool_t is an alias
to bool. Going forward, therer is a preference to use bool rather than
bool_t. Also replace 0 and 1 by false and true when relevant.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Since commit 9202342 "xen/build: Use C99 booleans", bool_t is an alias
to bool. Going forward, there is a preference to use bool rather than
bool_t. Also replace 0 and 1 by true and false when relevant.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The read variable can only take two values: 1 => read, 0 => write. Use
bool instead to make clear the variable can only take 2 values.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The emulation functions are always returning 0 or 1. Use bool instead to
make clear only two possible values exist.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Recent Linux kernel (4.4 and onwards [1]) is checking whether it is possible
to enable sysreg access (ICC_SRE_EL1.SRE) when the ID register
(ID_AA64PRF0_EL1.GIC) is reporting the presence of the sysreg interface.
When the guest has been configured to use GICv2, the hypervisor will
disable sysreg access for this vm (via ICC_SRE_EL2.Enable) and therefore
access to system register such as ICC_SRE_EL1 are trapped in EL2.
However, ICC_SRE_EL1 is not emulated by the hypervisor. This means that
Linux will crash as soon as it is trying to access ICC_SRE_EL1.
To solve this problem, Xen can implement ICC_SRE_EL1 as read-as-zero
write-ignore. The emulation will only be used when sysreg are disabled
for EL1.
[1] 963fcd409 "arm64: cpufeatures: Check ICC_EL1_SRE.SRE before
enabling ARM64_HAS_SYSREG_GIC_CPUIF"
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The tools (such as mk_dsdt) can be cross-built when it may not be
desirable to build them on the target.
The commit c4ac1077 "libxl/arm: Generate static ACPI DSDT table"
introduced support of ARM64 in mk_dsdt but also break cross-building
tools because the ACPI tables are not correct.
While mk_dsdt should generate ACPI table for the target architecture, it
currently generates the one for the host. This is because the source
code contains reference to the host architecture (__aarch64__,
__x86_64__, __i386__) when it should be the target architecture.
Replace all __aarch64__, __x86_64__, __i386__ by the corresponding
CONFIG_*.
Also expose the CONFIG_* to the source code as the currently only
exposed to the Makefile.
Reported-by: Andrii Anisov <andrii.anisov@gmail.com>
Suggested-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
The variable debug is used to enable debug for the tools. As
early-printk is for the hypervisor we should use CONFIG_DEBUG.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Earlier patches exported the p2m interface (p2m_get_entry and
p2m_set_entry) to allow splitting xen/arch/arm/p2m.c. Those functions
require the callers to lock the p2m, so we need to export p2m_*_lock
helpers.
All helpers but p2m_write_unlock but p2m_write_unlock are moved in
xen/include/asm-arm/p2m.h to allow inlining. The helpers
p2m_write_unlock is kept in p2m.c because it depends on a static
function.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
The function p2m_set_mem_access can be re-implemented using the generic
functions p2m_get_entry and __p2m_set_entry.
Also the function apply_p2m_changes is dropped completely as it is not
used anymore.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
The function p2m_insert_mapping can be re-implemented using the generic
function p2m_set_entry.
Note that the mapping is not reverted anymore if Xen fails to insert a
mapping. This was added to ensure the MMIO are not kept half-mapped
in case of failure and to follow the x86 counterpart. This was removed
on the x86 part by commit c3c756bd "x86/p2m: use large pages for MMIO
mappings" and I think we should let the caller taking care of it.
Finally drop the operation INSERT in apply_* as nobody is using it
anymore. Note that the functions could have been dropped in one go at the
end, however I find easier to drop the operations one by one avoiding a
big deletion in the patch that convert the last operation.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
The function p2m_insert_mapping can be re-implemented using the generic
function p2m_set_entry.
Also drop the operation REMOVE in apply_* as nobody is using it anymore.
Note that the functions could have been dropped in one go at the end,
however I find easier to drop the operations one by one avoiding a big
deletion in the patch that converts the last operation.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabelini <sstabellini@kernel.org>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
The function relinquish_p2m_mapping can be re-implemented using
p2m_{get,set}_entry by iterating over the range mapped and using the
mapping order given by the callee.
Given that the preemption was chosen arbitrarily, it is now done on every
512 iterations. Meaning that Xen may check more often if the function is
preempted when there are no mappings.
Finally drop the operation RELINQUISH in apply_* as nobody is using it
anymore. Note that the functions could have been dropped in one go at
the end, however I find easier to drop the operations one by one
avoiding a big deletion in the patch that remove the last operation.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
The ARM architecture mandates to use of a break-before-make sequence
when changing translation entries if the page table is shared between
multiple CPUs whenever a valid entry is replaced by another valid entry
(see D4.7.1 in ARM DDI 0487A.j for more details).
The break-before-make sequence can be divided in the following steps:
1) Invalidate the old entry in the page table
2) Issue a TLB invalidation instruction for the address associated
to this entry
3) Write the new entry
The current P2M code implemented in apply_one_level does not respect
this sequence and may result to break coherency on some processors.
Adapting the current implementation to use the break-before-make
sequence would imply some code duplication and more TLBs invalidation
than necessary. For instance, if we are replacing a 4KB page and the
current mapping in the P2M is using a 1GB superpage, the following steps
will happen:
1) Shatter the 1GB superpage into a series of 2MB superpages
2) Shatter the 2MB superpage into a series of 4KB pages
3) Replace the 4KB page
As the current implementation is shattering while descending and install
the mapping, Xen would need to issue 3 TLB invalidation instructions
which is clearly inefficient.
Furthermore, all the operations which modify the page table are using
the same skeleton. It is more complicated to maintain different code paths
than having a generic function that set an entry and take care of the
break-before-make sequence.
The new implementation is based on the x86 EPT one which, I think,
fits quite well for the break-before-make sequence whilst keeping
the code simple.
The main function of the new implementation is __p2m_set_entry. It will
only work on mapping that are aligned to a block entry in the page table
(i.e 1GB, 2MB, 4KB when using a 4KB granularity).
Another function, p2m_set_entry, is provided to break down is region
into mapping that is aligned to a block entry or 4KB when memaccess is
enabled.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
Use the level and the entry to know whether an entry is a superpage.
A superpage can only happen below level 3.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
Those helpers are very small and often used. Let know the compiler they
can be inlined.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
The function p2m_cache_flush can be re-implemented using the generic
function p2m_get_entry by iterating over the range and using the mapping
order given by the callee.
As the current implementation, no preemption is implemented, although
the comment in the current code claimed it. As the function is called by
a DOMCTL with a region of 1GB maximum, I think the preemption can be
left unimplemented for now.
Finally drop the operation CACHEFLUSH in apply_one_level as nobody is
using it anymore. Note that the function could have been dropped in one
go at the end, however I find easier to drop the operations one by one
avoiding a big deletion in the patch that convert the last operation.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
Currently, for a given GFN, the function __p2m_lookup will only return
the associated MFN and the p2m type of the mapping.
In some case we need the order of the mapping and the memaccess
permission. Rather than providing a separate function for this purpose,
it is better to implement a generic function to return all the
information.
To avoid passing dummy parameter, a caller that does not need a
specific information can use NULL instead.
The list of the informations retrieved is based on the x86 version. All
of them will be used in follow-up patches.
It might have been possible to extend __p2m_lookup, however I choose to
reimplement it from scratch to allow sharing some helpers with the
function that will update the P2M (will be added in a follow-up patch).
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
Mapping the root table is always done the same way. To avoid duplicating
the code in a later patch, move the code in a separate helper.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
Julien Grall