Eric Lee / smarc-fsl-linux-kernel

10 Jan, 2020

1 commit

  • b6a5c5824   arm64: xen: Use modern annotations for assembly functions ... Browse Code »

    In an effort to clarify and simplify the annotation of assembly functions
    in the kernel new macros have been introduced. These replace ENTRY and
    ENDPROC. Update the annotations in the xen code to the new macros.

    Signed-off-by: Mark Brown
    Reviewed-by: Julien Grall
    Reviewed-by: Stefano Stabellini
    Signed-off-by: Will Deacon

    Mark Brown
     

02 Oct, 2019

1 commit

  • 095157068   xen/efi: have a common runtime setup function ... Browse Code »

    Today the EFI runtime functions are setup in architecture specific
    code (x86 and arm), with the functions themselves living in drivers/xen
    as they are not architecture dependent.

    As the setup is exactly the same for arm and x86 move the setup to
    drivers/xen, too. This at once removes the need to make the single
    functions global visible.

    Signed-off-by: Juergen Gross
    Reviewed-by: Jan Beulich
    [boris: "Dropped EXPORT_SYMBOL_GPL(xen_efi_runtime_setup)"]
    Signed-off-by: Boris Ostrovsky

    Juergen Gross
     

21 May, 2019

1 commit

17 Jan, 2018

1 commit

  • 6b88a32c7   arm64: kpti: Fix the interaction between ASID switching and software PAN ... Browse Code »

    With ARM64_SW_TTBR0_PAN enabled, the exception entry code checks the
    active ASID to decide whether user access was enabled (non-zero ASID)
    when the exception was taken. On return from exception, if user access
    was previously disabled, it re-instates TTBR0_EL1 from the per-thread
    saved value (updated in switch_mm() or efi_set_pgd()).

    Commit 7655abb95386 ("arm64: mm: Move ASID from TTBR0 to TTBR1") makes a
    TTBR0_EL1 + ASID switching non-atomic. Subsequently, commit 27a921e75711
    ("arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN") changes the
    __uaccess_ttbr0_disable() function and asm macro to first write the
    reserved TTBR0_EL1 followed by the ASID=0 update in TTBR1_EL1. If an
    exception occurs between these two, the exception return code will
    re-instate a valid TTBR0_EL1. Similar scenario can happen in
    cpu_switch_mm() between setting the reserved TTBR0_EL1 and the ASID
    update in cpu_do_switch_mm().

    This patch reverts the entry.S check for ASID == 0 to TTBR0_EL1 and
    disables the interrupts around the TTBR0_EL1 and ASID switching code in
    __uaccess_ttbr0_disable(). It also ensures that, when returning from the
    EFI runtime services, efi_set_pgd() doesn't leave a non-zero ASID in
    TTBR1_EL1 by using uaccess_ttbr0_{enable,disable}.

    The accesses to current_thread_info()->ttbr0 are updated to use
    READ_ONCE/WRITE_ONCE.

    As a safety measure, __uaccess_ttbr0_enable() always masks out any
    existing non-zero ASID TTBR1_EL1 before writing in the new ASID.

    Fixes: 27a921e75711 ("arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN")
    Acked-by: Will Deacon
    Reported-by: Ard Biesheuvel
    Tested-by: Ard Biesheuvel
    Reviewed-by: James Morse
    Tested-by: James Morse
    Co-developed-by: Marc Zyngier
    Signed-off-by: Catalin Marinas

    Catalin Marinas
     

11 Dec, 2017

1 commit

  • 27a921e75   arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN ... Browse Code »

    With the ASID now installed in TTBR1, we can re-enable ARM64_SW_TTBR0_PAN
    by ensuring that we switch to a reserved ASID of zero when disabling
    user access and restore the active user ASID on the uaccess enable path.

    Reviewed-by: Mark Rutland
    Tested-by: Laura Abbott
    Tested-by: Shanker Donthineni
    Signed-off-by: Will Deacon

    Will Deacon
     

15 Feb, 2017

1 commit

  • ab520be8c   xen/privcmd: Add IOCTL_PRIVCMD_DM_OP ... Browse Code »

    Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
    for restricting device emulators (such as QEMU) to a limited set of
    hypervisor operations, and being able to audit those operations in the
    kernel of the domain in which they run.

    This patch adds IOCTL_PRIVCMD_DM_OP as gateway for __HYPERVISOR_dm_op.

    NOTE: There is no requirement for user-space code to bounce data through
    locked memory buffers (as with IOCTL_PRIVCMD_HYPERCALL) since
    privcmd has enough information to lock the original buffers
    directly.

    [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=524a98c2

    Signed-off-by: Paul Durrant
    Acked-by: Stefano Stabellini
    Signed-off-by: Boris Ostrovsky

    Paul Durrant
     

27 Dec, 2016

1 commit

25 Dec, 2016

1 commit

22 Nov, 2016

1 commit

  • 9cf09d68b   arm64: xen: Enable user access before a privcmd hvc call ... Browse Code »

    Privcmd calls are issued by the userspace. The kernel needs to enable
    access to TTBR0_EL1 as the hypervisor would issue stage 1 translations
    to user memory via AT instructions. Since AT instructions are not
    affected by the PAN bit (ARMv8.1), we only need the explicit
    uaccess_enable/disable if the TTBR0 PAN option is enabled.

    Reviewed-by: Julien Grall
    Acked-by: Stefano Stabellini
    Cc: Will Deacon
    Cc: James Morse
    Cc: Kees Cook
    Cc: Mark Rutland
    Signed-off-by: Catalin Marinas

    Catalin Marinas
     

06 Jul, 2016

2 commits

21 Dec, 2015

1 commit

24 Apr, 2014

1 commit

  • 5e40704ed   arm: xen: implement multicall hypercall support. ... Browse Code »

    As part of this make the usual change to xen_ulong_t in place of unsigned long.
    This change has no impact on x86.

    The Linux definition of struct multicall_entry.result differs from the Xen
    definition, I think for good reasons, and used a long rather than an unsigned
    long. Therefore introduce a xen_long_t, which is a long on x86 architectures
    and a signed 64-bit integer on ARM.

    Use uint32_t nr_calls on x86 for consistency with the ARM definition.

    Build tested on amd64 and i386 builds. Runtime tested on ARM.

    Signed-off-by: Ian Campbell
    Cc: Stefano Stabellini
    Cc: Konrad Rzeszutek Wilk
    Cc: Boris Ostrovsky
    Signed-off-by: David Vrabel

    Ian Campbell
     

18 Oct, 2013

1 commit

  • 4a19138c6   arm/xen,arm64/xen: introduce p2m ... Browse Code »

    Introduce physical to machine and machine to physical tracking
    mechanisms based on rbtrees for arm/xen and arm64/xen.

    We need it because any guests on ARM are an autotranslate guests,
    therefore a physical address is potentially different from a machine
    address. When programming a device to do DMA, we need to be
    extra-careful to use machine addresses rather than physical addresses to
    program the device. Therefore we need to know the physical to machine
    mappings.

    For the moment we assume that dom0 starts with a 1:1 physical to machine
    mapping, in other words physical addresses correspond to machine
    addresses. However when mapping a foreign grant reference, obviously the
    1:1 model doesn't work anymore. So at the very least we need to be able
    to track grant mappings.

    We need locking to protect accesses to the two trees.

    Signed-off-by: Stefano Stabellini

    Changes in v8:
    - move pfn_to_mfn and mfn_to_pfn to page.h as static inline functions;
    - no need to walk the tree if phys_to_mach.rb_node is NULL;
    - correctly handle multipage p2m entries;
    - substitute the spin_lock with a rwlock.

    Stefano Stabellini
     

10 Oct, 2013

1 commit

  • 83862ccfc   xen/arm,arm64: enable SWIOTLB_XEN ... Browse Code »

    Xen on arm and arm64 needs SWIOTLB_XEN: when running on Xen we need to
    program the hardware with mfns rather than pfns for dma addresses.
    Remove SWIOTLB_XEN dependency on X86 and PCI and make XEN select
    SWIOTLB_XEN on arm and arm64.

    At the moment always rely on swiotlb-xen, but when Xen starts supporting
    hardware IOMMUs we'll be able to avoid it conditionally on the presence
    of an IOMMU on the platform.

    Implement xen_create_contiguous_region on arm and arm64: for the moment
    we assume that dom0 has been mapped 1:1 (physical addresses == machine
    addresses) therefore we don't need to call XENMEM_exchange. Simply
    return the physical address as dma address.

    Initialize the xen-swiotlb from xen_early_init (before the native
    dma_ops are initialized), set xen_dma_ops to &xen_swiotlb_dma_ops.

    Signed-off-by: Stefano Stabellini

    Changes in v8:
    - assume dom0 is mapped 1:1, no need to call XENMEM_exchange.

    Changes in v7:
    - call __set_phys_to_machine_multi from xen_create_contiguous_region and
    xen_destroy_contiguous_region to update the P2M;
    - don't call XENMEM_unpin, it has been removed;
    - call XENMEM_exchange instead of XENMEM_exchange_and_pin;
    - set nr_exchanged to 0 before calling the hypercall.

    Changes in v6:
    - introduce and export xen_dma_ops;
    - call xen_mm_init from as arch_initcall.

    Changes in v4:
    - remove redefinition of DMA_ERROR_CODE;
    - update the code to use XENMEM_exchange_and_pin and XENMEM_unpin;
    - add a note about hardware IOMMU in the commit message.

    Changes in v3:
    - code style changes;
    - warn on XENMEM_put_dma_buf failures.

    Stefano Stabellini
     

04 Jul, 2013

1 commit

07 Jun, 2013

1 commit