linux-toradex.git/arch/arm/xen, branch v3.16-rc2

arm,arm64/xen: introduce HYPERVISOR_suspend()

2014-05-12T16:20:24+00:00

Introduce HYPERVISOR_suspend() and a few additional empty stubs for
Xen arch specific functions called by drivers/xen/manage.c.

Signed-off-by: Stefano Stabellini 
Signed-off-by: David Vrabel

arm: xen: export HYPERVISOR_multicall to modules.

2014-05-09T16:10:49+00:00

"arm: xen: implement multicall hypercall support." forgot to do this.

Signed-off-by: Ian Campbell 
Signed-off-by: Stefano Stabellini

arm: xen: implement multicall hypercall support.

2014-04-24T12:09:46+00:00

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

xen/grant-table: Refactor gnttab_[un]map_refs to avoid m2p_override

2014-03-18T14:40:19+00:00

The grant mapping API does m2p_override unnecessarily: only gntdev needs it,
for blkback and future netback patches it just cause a lock contention, as
those pages never go to userspace. Therefore this series does the following:
- the bulk of the original function (everything after the mapping hypercall)
  is moved to arch-dependent set/clear_foreign_p2m_mapping
- the "if (xen_feature(XENFEAT_auto_translated_physmap))" branch goes to ARM
- therefore the ARM function could be much smaller, the m2p_override stubs
  could be also removed
- on x86 the set_phys_to_machine calls were moved up to this new funcion
  from m2p_override functions
- and m2p_override functions are only called when there is a kmap_ops param

It also removes a stray space from arch/x86/include/asm/xen/page.h.

Signed-off-by: Zoltan Kiss 
Suggested-by: Anthony Liguori 
Suggested-by: David Vrabel 
Suggested-by: Stefano Stabellini 
Signed-off-by: David Vrabel 
Signed-off-by: Stefano Stabellini

xen/gnttab: Use phys_addr_t to describe the grant frame base address

2014-01-30T12:56:34+00:00

On ARM, address size can be 32 bits or 64 bits (if CONFIG_ARCH_PHYS_ADDR_T_64BIT
is enabled).
We can't assume that the grant frame base address will always fits in an
unsigned long. Use phys_addr_t instead of unsigned long as argument for
gnttab_setup_auto_xlat_frames.

Signed-off-by: Julien Grall 
Signed-off-by: Stefano Stabellini 
Acked-by: Ian Campbell 
Reviewed-by: David Vrabel

arm/xen: Initialize event channels earlier

2014-01-30T12:52:59+00:00

Event channels driver needs to be initialized very early. Until now, Xen
initialization was done after all CPUs was bring up.

We can safely move the initialization to an early initcall.

Also use a cpu notifier to:
    - Register the VCPU when the CPU is prepared
    - Enable event channel IRQ when the CPU is running

Signed-off-by: Julien Grall 
Signed-off-by: Stefano Stabellini

xen/grant: Implement an grant frame array struct (v3).

2014-01-06T15:44:20+00:00

The 'xen_hvm_resume_frames' used to be an 'unsigned long'
and contain the virtual address of the grants. That was OK
for most architectures (PVHVM, ARM) were the grants are contiguous
in memory. That however is not the case for PVH - in which case
we will have to do a lookup for each virtual address for the PFN.

Instead of doing that, lets make it a structure which will contain
the array of PFNs, the virtual address and the count of said PFNs.

Also provide a generic functions: gnttab_setup_auto_xlat_frames and
gnttab_free_auto_xlat_frames to populate said structure with
appropriate values for PVHVM and ARM.

To round it off, change the name from 'xen_hvm_resume_frames' to
a more descriptive one - 'xen_auto_xlat_grant_frames'.

For PVH, in patch "xen/pvh: Piggyback on PVHVM for grant driver"
we will populate the 'xen_auto_xlat_grant_frames' by ourselves.

v2 moves the xen_remap in the gnttab_setup_auto_xlat_frames
and also introduces xen_unmap for gnttab_free_auto_xlat_frames.

Suggested-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
[v3: Based on top of 'asm/xen/page.h: remove redundant semicolon']
Acked-by: Stefano Stabellini

arm: xen: foreign mapping PTEs are special.

2013-12-11T17:06:05+00:00

These mappings are in fact special and require special handling in privcmd,
which already exists. Failure to mark the PTE as special on arm64 causes all
sorts of bad PTE fun. e.g.

e.g.:

BUG: Bad page map in process xl  pte:e0004077b33f53 pmd:4079575003
page:ffffffbce1a2f328 count:1 mapcount:-1 mapping:          (null) index:0x0
page flags: 0x4000000000000014(referenced|dirty)
addr:0000007fb5259000 vm_flags:040644fa anon_vma:          (null) mapping:ffffffc03a6fda58 index:0
vma->vm_ops->fault: privcmd_fault+0x0/0x38
vma->vm_file->f_op->mmap: privcmd_mmap+0x0/0x2c
CPU: 0 PID: 2657 Comm: xl Not tainted 3.12.0+ #102
Call trace:
[] dump_backtrace+0x0/0x12c
[] show_stack+0x14/0x1c
[] dump_stack+0x70/0x90
[] print_bad_pte+0x12c/0x1bc
[] unmap_single_vma+0x4cc/0x700
[] unmap_vmas+0x68/0xb4
[] unmap_region+0xcc/0x1d4
[] do_munmap+0x218/0x314
[] vm_munmap+0x44/0x64
[] SyS_munmap+0x24/0x34

Where unmap_single_vma contains inlined -> unmap_page_range -> zap_pud_range
-> zap_pmd_range -> zap_pte_range -> print_bad_pte.

Or:

BUG: Bad page state in process xl  pfn:4077b4d
page:ffffffbce1a2f8d8 count:0 mapcount:-1 mapping:          (null) index:0x0
page flags: 0x4000000000000014(referenced|dirty)
Modules linked in:
CPU: 0 PID: 2657 Comm: xl Tainted: G    B        3.12.0+ #102
Call trace:
[] dump_backtrace+0x0/0x12c
[] show_stack+0x14/0x1c
[] dump_stack+0x70/0x90
[] bad_page+0xc4/0x110
[] free_pages_prepare+0xd0/0xd8
[] free_hot_cold_page+0x28/0x178
[] free_hot_cold_page_list+0x38/0x60
[] release_pages+0x190/0x1dc
[] unmap_region+0x15c/0x1d4
[] do_munmap+0x218/0x314
[] vm_munmap+0x44/0x64
[] SyS_munmap+0x24/0x34

x86 already gets this correct. 32-bit arm gets away with this because there is
not PTE_SPECIAL bit in the PTE there and the vm_normal_page fallback path does
the right thing.

Signed-off-by: Ian Campbell 
Signed-off-by: Stefano Stabellini

XEN: Grant table address, xen_hvm_resume_frames, is a phys_addr not a pfn

2013-12-04T11:39:33+00:00

From: Eric Trudeau 

xen_hvm_resume_frames stores the physical address of the grant table.
englighten.c was incorrectly setting it as if it was a page frame number.
This caused the table to be mapped into the guest at an unexpected physical
address.

Additionally, a warning is improved to include the grant table address which
failed in xen_remap.

Signed-off-by: Eric Trudeau 
Signed-off-by: Stefano Stabellini

xen/arm: p2m_init and p2m_lock should be static

2013-11-18T15:33:10+00:00

Signed-off-by: Stefano Stabellini