aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-09-08xen/xenbus: Rename the variable xen_store_mfn to xen_store_gfnJulien Grall1-7/+7
The variable xen_store_mfn is effectively storing a GFN and not an MFN. Signed-off-by: Julien Grall <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-09-08xen/privcmd: Further s/MFN/GFN/ clean-upJulien Grall6-61/+65
The privcmd code is mixing the usage of GFN and MFN within the same functions which make the code difficult to understand when you only work with auto-translated guests. The privcmd driver is only dealing with GFN so replace all the mention of MFN into GFN. The ioctl structure used to map foreign change has been left unchanged given that the userspace is using it. Nonetheless, add a comment to explain the expected value within the "mfn" field. Signed-off-by: Julien Grall <[email protected]> Reviewed-by: David Vrabel <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-09-08hvc/xen: Further s/MFN/GFN clean-upJulien Grall1-10/+5
HVM_PARAM_CONSOLE_PFN is used to retrieved the console PFN for HVM guest. It returns a PFN (aka GFN) and not a MFN. Furthermore, use directly virt_to_gfn for both PV and HVM domain rather than doing a special case for each of the them. Signed-off-by: Julien Grall <[email protected]> Reviewed-by: David Vrabel <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-09-08video/xen-fbfront: Further s/MFN/GFN clean-upJulien Grall1-9/+9
The PV driver xen-fbfront is only dealing with GFN and not MFN. Rename all the occurence of MFN to GFN. Also take the opportunity to replace to usage of pfn_to_gfn by xen_page_to_gfn. Signed-off-by: Julien Grall <[email protected]> Reviewed-by: David Vrabel <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-09-08xen/tmem: Use xen_page_to_gfn rather than pfn_to_gfnJulien Grall1-16/+8
All the caller of xen_tmem_{get,put}_page have a struct page * in hand and call pfn_to_gfn for the only benefits of these 2 functions. Rather than passing the pfn in parameter, pass directly the page and use directly xen_page_to_gfn. Signed-off-by: Julien Grall <[email protected]> Reviewed-by: Stefano Stabellini <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-09-08xen: Use correctly the Xen memory terminologiesJulien Grall20-47/+81
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN is meant, I suspect this is because the first support for Xen was for PV. This resulted in some misimplementation of helpers on ARM and confused developers about the expected behavior. For instance, with pfn_to_mfn, we expect to get an MFN based on the name. Although, if we look at the implementation on x86, it's returning a GFN. For clarity and avoid new confusion, replace any reference to mfn with gfn in any helpers used by PV drivers. The x86 code will still keep some reference of pfn_to_mfn which may be used by all kind of guests No changes as been made in the hypercall field, even though they may be invalid, in order to keep the same as the defintion in xen repo. Note that page_to_mfn has been renamed to xen_page_to_gfn to avoid a name to close to the KVM function gfn_to_page. Take also the opportunity to simplify simple construction such as pfn_to_mfn(page_to_pfn(page)) into xen_page_to_gfn. More complex clean up will come in follow-up patches. [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb Signed-off-by: Julien Grall <[email protected]> Reviewed-by: Stefano Stabellini <[email protected]> Acked-by: Dmitry Torokhov <[email protected]> Acked-by: Wei Liu <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-09-08arm/xen: implement correctly pfn_to_mfnJulien Grall1-8/+0
After the commit introducing convertion between DMA and guest addresses, all the callers of pfn_to_mfn are expecting to get a GFN (Guest Frame Number). On ARM, all the guests are auto-translated so the GFN is equal to the Linux PFN (Pseudo-physical Frame Number). The current implementation may return an MFN if the caller is passing a PFN associated to a mapped foreign grant. In pratice, I haven't seen the problem on running guest but we should fix it for the sake of correctness. Correct the implementation by always returning the pfn passed in parameter. A follow-up patch will take care to rename pfn_to_mfn to a suitable name. Signed-off-by: Julien Grall <[email protected]> Reviewed-by: Stefano Stabellini <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-09-08xen: Make clear that swiotlb and biomerge are dealing with DMA addressJulien Grall5-17/+40
The swiotlb is required when programming a DMA address on ARM when a device is not protected by an IOMMU. In this case, the DMA address should always be equal to the machine address. For DOM0 memory, Xen ensure it by have an identity mapping between the guest address and host address. However, when mapping a foreign grant reference, the 1:1 model doesn't work. For ARM guest, most of the callers of pfn_to_mfn expects to get a GFN (Guest Frame Number), i.e a PFN (Page Frame Number) from the Linux point of view given that all ARM guest are auto-translated. Even though the name pfn_to_mfn is misleading, we need to ensure that those caller get a GFN and not by mistake a MFN. In pratical, I haven't seen error related to this but we should fix it for the sake of correctness. In order to fix the implementation of pfn_to_mfn on ARM in a follow-up patch, we have to introduce new helpers to return the DMA from a PFN and the invert. On x86, the new helpers will be an alias of pfn_to_mfn and mfn_to_pfn. The helpers will be used in swiotlb and xen_biovec_phys_mergeable. This is necessary in the latter because we have to ensure that the biovec code will not try to merge a biovec using foreign page and another using Linux memory. Lastly, the helper mfn_to_local_pfn has been renamed to bfn_to_local_pfn given that the only usage was in swiotlb. Signed-off-by: Julien Grall <[email protected]> Reviewed-by: Stefano Stabellini <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-09-08xen: switch extra memory accounting to use pfnsJuergen Gross3-41/+49
Instead of using physical addresses for accounting of extra memory areas available for ballooning switch to pfns as this is much less error prone regarding partial pages. Reported-by: Roger Pau Monné <[email protected]> Tested-by: Roger Pau Monné <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-09-08xen: limit memory to architectural maximumJuergen Gross1-1/+1
When a pv-domain (including dom0) is started it tries to size it's p2m list according to the maximum possible memory amount it ever can achieve. Limit the initial maximum memory size to the architectural limit of the hardware in order to avoid overflows during remapping of memory. This problem will occur when dom0 is started with an initial memory size being a multiple of 1GB, but without specifying it's maximum memory size. The kernel must be configured without CONFIG_XEN_BALLOON_MEMORY_HOTPLUG for the problem to happen. Reported-by: Roger Pau Monné <[email protected]> Tested-by: Roger Pau Monné <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-09-08xen: avoid another early crash of memory limited dom0Juergen Gross1-8/+15
Commit b1c9f169047b ("xen: split counting of extra memory pages...") introduced an error when dom0 was started with limited memory occurring only on some hardware. The problem arises in case dom0 is started with initial memory and maximum memory being the same. The kernel must be configured without CONFIG_XEN_BALLOON_MEMORY_HOTPLUG for the problem to happen. If all of this is true and the E820 map of the machine is sparse (some areas are not covered) then the machine might crash early in the boot process. An example E820 map triggering the problem looks like this: [ 0.000000] e820: BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000cf7fafff] usable [ 0.000000] BIOS-e820: [mem 0x00000000cf7fb000-0x00000000cf95ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000cf960000-0x00000000cfb62fff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000cfb63000-0x00000000cfd14fff] usable [ 0.000000] BIOS-e820: [mem 0x00000000cfd15000-0x00000000cfd61fff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000cfd62000-0x00000000cfd6cfff] ACPI data [ 0.000000] BIOS-e820: [mem 0x00000000cfd6d000-0x00000000cfd6ffff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000cfd70000-0x00000000cfd70fff] usable [ 0.000000] BIOS-e820: [mem 0x00000000cfd71000-0x00000000cfea8fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000cfea9000-0x00000000cfeb9fff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000cfeba000-0x00000000cfecafff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000cfecb000-0x00000000cfecbfff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000cfecc000-0x00000000cfedbfff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000cfedc000-0x00000000cfedcfff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000cfedd000-0x00000000cfeddfff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000cfede000-0x00000000cfee3fff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000cfee4000-0x00000000cfef6fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000cfef7000-0x00000000cfefffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec10000-0x00000000fec10fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed40000-0x00000000fed44fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed61000-0x00000000fed70fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100001000-0x000000020effffff] usable In this case the area a0000-dffff isn't present in the map. This will confuse the memory setup of the domain when remapping the memory from such holes to populated areas. To avoid the problem the accounting of to be remapped memory has to count such holes in the E820 map as well. Reported-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-09-08xen: avoid early crash of memory limited dom0Juergen Gross1-3/+4
Commit b1c9f169047b ("xen: split counting of extra memory pages...") introduced an error when dom0 was started with limited memory. The problem arises in case dom0 is started with initial memory and maximum memory being the same and exactly a multiple of 1 GB. The kernel must be configured without CONFIG_XEN_BALLOON_MEMORY_HOTPLUG for the problem to happen. In this case it will crash very early during boot due to the virtual mapped p2m list not being large enough to be able to remap any memory: (XEN) Freed 304kB init memory. mapping kernel into physical memory about to get started... (XEN) traps.c:459:d0v0 Unhandled invalid opcode fault/trap [#6] on VCPU 0 [ec=0000] (XEN) domain_crash_sync called from entry.S: fault at ffff82d080229a93 create_bounce_frame+0x12b/0x13a (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) ----[ Xen-4.5.2-pre x86_64 debug=n Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e033:[<ffffffff81d120cb>] (XEN) RFLAGS: 0000000000000206 EM: 1 CONTEXT: pv guest (d0v0) (XEN) rax: ffffffff81db2000 rbx: 000000004d000000 rcx: 0000000000000000 (XEN) rdx: 000000004d000000 rsi: 0000000000063000 rdi: 000000004d063000 (XEN) rbp: ffffffff81c03d78 rsp: ffffffff81c03d28 r8: 0000000000023000 (XEN) r9: 00000001040ff000 r10: 0000000000007ff0 r11: 0000000000000000 (XEN) r12: 0000000000063000 r13: 000000000004d000 r14: 0000000000000063 (XEN) r15: 0000000000000063 cr0: 0000000080050033 cr4: 00000000000006f0 (XEN) cr3: 0000000105c0f000 cr2: ffffc90000268000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=ffffffff81c03d28: (XEN) 0000000000000000 0000000000000000 ffffffff81d120cb 000000010000e030 (XEN) 0000000000010006 ffffffff81c03d68 000000000000e02b ffffffffffffffff (XEN) 0000000000000063 000000000004d063 ffffffff81c03de8 ffffffff81d130a7 (XEN) ffffffff81c03de8 000000000004d000 00000001040ff000 0000000000105db1 (XEN) 00000001040ff001 000000000004d062 ffff8800092d6ff8 0000000002027000 (XEN) ffff8800094d8340 ffff8800092d6ff8 00003ffffffff000 ffff8800092d7ff8 (XEN) ffffffff81c03e48 ffffffff81d13c43 ffff8800094d8000 ffff8800094d9000 (XEN) 0000000000000000 ffff8800092d6000 00000000092d6000 000000004cfbf000 (XEN) 00000000092d6000 00000000052d5442 0000000000000000 0000000000000000 (XEN) ffffffff81c03ed8 ffffffff81d185c1 0000000000000000 0000000000000000 (XEN) ffffffff81c03e78 ffffffff810f8ca4 ffffffff81c03ed8 ffffffff8171a15d (XEN) 0000000000000010 ffffffff81c03ee8 0000000000000000 0000000000000000 (XEN) ffffffff81f0e402 ffffffffffffffff ffffffff81dae900 0000000000000000 (XEN) 0000000000000000 0000000000000000 ffffffff81c03f28 ffffffff81d0cf0f (XEN) 0000000000000000 0000000000000000 0000000000000000 ffffffff81db82e0 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) ffffffff81c03f38 ffffffff81d0c603 ffffffff81c03ff8 ffffffff81d11c86 (XEN) 0300000100000032 0000000000000005 0000000000000020 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) Domain 0 crashed: rebooting machine in 5 seconds. This can be avoided by allocating aneough space for the p2m to cover the maximum memory of dom0 plus the identity mapped holes required for PCI space, BIOS etc. Reported-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20arm/xen: Remove helpers which are PV specificJulien Grall1-14/+2
ARM guests are always HVM. The current implementation is assuming a 1:1 mapping which is only true for DOM0 and may not be at all in the future. Furthermore, all the helpers but arbitrary_virt_to_machine are used in x86 specific code (or only compiled for). The helper arbitrary_virt_to_machine is only used in PV specific code. Therefore we should never call the function. Add a BUG() in this helper and drop all the others. Signed-off-by: Julien Grall <[email protected]> Acked-by: Stefano Stabellini <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen/x86: Don't try to set PCE bit in CR4Boris Ostrovsky1-2/+1
Since VPMU code emulates RDPMC instruction with RDMSR and because hypervisor does not emulate it there is no reason to try setting CR4's PCE bit (and the hypervisor will warn on seeing it set). Signed-off-by: Boris Ostrovsky <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen/PMU: PMU emulation codeBoris Ostrovsky1-29/+185
Add PMU emulation code that runs when we are processing a PMU interrupt. This code will allow us not to trap to hypervisor on each MSR/LVTPC access (of which there may be quite a few in the handler). Signed-off-by: Boris Ostrovsky <[email protected]> Reviewed-by: David Vrabel <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen/PMU: Intercept PMU-related MSR and APIC accessesBoris Ostrovsky5-8/+109
Provide interfaces for recognizing accesses to PMU-related MSRs and LVTPC APIC and process these accesses in Xen PMU code. (The interrupt handler performs XENPMU_flush right away in the beginning since no PMU emulation is available. It will be added with a later patch). Signed-off-by: Boris Ostrovsky <[email protected]> Reviewed-by: David Vrabel <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen/PMU: Describe vendor-specific PMU registersBoris Ostrovsky1-1/+152
AMD and Intel PMU register initialization and helpers that determine whether a register belongs to PMU. This and some of subsequent PMU emulation code is somewhat similar to Xen's PMU implementation. Signed-off-by: Boris Ostrovsky <[email protected]> Reviewed-by: David Vrabel <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen/PMU: Initialization code for Xen PMUBoris Ostrovsky10-9/+398
Map shared data structure that will hold CPU registers, VPMU context, V/PCPU IDs of the CPU interrupted by PMU interrupt. Hypervisor fills this information in its handler and passes it to the guest for further processing. Set up PMU VIRQ. Now that perf infrastructure will assume that PMU is available on a PV guest we need to be careful and make sure that accesses via RDPMC instruction don't cause fatal traps by the hypervisor. Provide a nop RDPMC handler. For the same reason avoid issuing a warning on a write to APIC's LVTPC. Both of these will be made functional in later patches. Signed-off-by: Boris Ostrovsky <[email protected]> Reviewed-by: David Vrabel <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen/PMU: Sysfs interface for setting Xen PMU modeBoris Ostrovsky7-1/+228
Set Xen's PMU mode via /sys/hypervisor/pmu/pmu_mode. Add XENPMU hypercall. Signed-off-by: Boris Ostrovsky <[email protected]> Reviewed-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: xensyms supportBoris Ostrovsky6-0/+183
Export Xen symbols to dom0 via /proc/xen/xensyms (similar to /proc/kallsyms). Signed-off-by: Boris Ostrovsky <[email protected]> Reviewed-by: David Vrabel <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: remove no longer needed p2m.hJuergen Gross4-19/+9
Cleanup by removing arch/x86/xen/p2m.h as it isn't needed any more. Most definitions in this file are used in p2m.c only. Move those into p2m.c. set_phys_range_identity() is already declared in arch/x86/include/asm/xen/page.h, add __init annotation there. MAX_REMAP_RANGES isn't used at all, just delete it. The only define left is P2M_PER_PAGE which is moved to page.h as well. Signed-off-by: Juergen Gross <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: allow more than 512 GB of RAM for 64 bit pv-domainsJuergen Gross5-27/+73
64 bit pv-domains under Xen are limited to 512 GB of RAM today. The main reason has been the 3 level p2m tree, which was replaced by the virtual mapped linear p2m list. Parallel to the p2m list which is being used by the kernel itself there is a 3 level mfn tree for usage by the Xen tools and eventually for crash dump analysis. For this tree the linear p2m list can serve as a replacement, too. As the kernel can't know whether the tools are capable of dealing with the p2m list instead of the mfn tree, the limit of 512 GB can't be dropped in all cases. This patch replaces the hard limit by a kernel parameter which tells the kernel to obey the 512 GB limit or not. The default is selected by a configuration parameter which specifies whether the 512 GB limit should be active per default for domUs (domain save/restore/migration and crash dump analysis are affected). Memory above the domain limit is returned to the hypervisor instead of being identity mapped, which was wrong anyway. The kernel configuration parameter to specify the maximum size of a domain can be deleted, as it is not relevant any more. Signed-off-by: Juergen Gross <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: move p2m list if conflicting with e820 mapJuergen Gross3-47/+264
Check whether the hypervisor supplied p2m list is placed at a location which is conflicting with the target E820 map. If this is the case relocate it to a new area unused up to now and compliant to the E820 map. As the p2m list might by huge (up to several GB) and is required to be mapped virtually, set up a temporary mapping for the copied list. For pvh domains just delete the p2m related information from start info instead of reserving the p2m memory, as we don't need it at all. For 32 bit kernels adjust the memblock_reserve() parameters in order to cover the page tables only. This requires to memblock_reserve() the start_info page on it's own. Signed-off-by: Juergen Gross <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: add explicit memblock_reserve() calls for special pagesJuergen Gross3-1/+19
Some special pages containing interfaces to xen are being reserved implicitly only today. The memblock_reserve() call to reserve them is meant to reserve the p2m list supplied by xen. It is just reserving not only the p2m list itself, but some more pages up to the start of the xen built page tables. To be able to move the p2m list to another pfn range, which is needed for support of huge RAM, this memblock_reserve() must be split up to cover all affected reserved pages explicitly. The affected pages are: - start_info page - xenstore ring (might be missing, mfn is 0 in this case) - console ring (not for initial domain) Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20mm: provide early_memremap_ro to establish read-only mappingJuergen Gross3-0/+17
During early boot as Xen pv domain the kernel needs to map some page tables supplied by the hypervisor read only. This is needed to be able to relocate some data structures conflicting with the physical memory map especially on systems with huge RAM (above 512GB). Provide the function early_memremap_ro() to provide this read only mapping. Signed-off-by: Juergen Gross <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: check for initrd conflicting with e820 mapJuergen Gross1-0/+51
Check whether the initrd is placed at a location which is conflicting with the target E820 map. If this is the case relocate it to a new area unused up to now and compliant to the E820 map. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: David Vrabel <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: check pre-allocated page tables for conflict with memory mapJuergen Gross3-3/+23
Check whether the page tables built by the domain builder are at memory addresses which are in conflict with the target memory map. If this is the case just panic instead of running into problems later. Signed-off-by: Juergen Gross <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: check for kernel memory conflicting with memory layoutJuergen Gross1-0/+12
Checks whether the pre-allocated memory of the loaded kernel is in conflict with the target memory map. If this is the case, just panic instead of run into problems later, as there is nothing we can do to repair this situation. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: David Vrabel <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: find unused contiguous memory areaJuergen Gross2-0/+35
For being able to relocate pre-allocated data areas like initrd or p2m list it is mandatory to find a contiguous memory area which is not yet in use and doesn't conflict with the memory map we want to be in effect. In case such an area is found reserve it at once as this will be required to be done in any case. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: David Vrabel <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: check memory area against e820 mapJuergen Gross2-0/+24
Provide a service routine to check a physical memory area against the E820 map. The routine will return false if the complete area is RAM according to the E820 map and true otherwise. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: David Vrabel <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: split counting of extra memory pages from remappingJuergen Gross1-40/+58
Memory pages in the initial memory setup done by the Xen hypervisor conflicting with the target E820 map are remapped. In order to do this those pages are counted and remapped in xen_set_identity_and_remap(). Split the counting from the remapping operation to be able to setup the needed memory sizes in time but doing the remap operation at a later time. This enables us to simplify the interface to xen_set_identity_and_remap() as the number of remapped and released pages is no longer needed here. Finally move the remapping further down to prepare relocating conflicting memory contents before the memory might be clobbered by xen_set_identity_and_remap(). This requires to not destroy the Xen E820 map when the one for the system is being constructed. Signed-off-by: Juergen Gross <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: move static e820 map to global scopeJuergen Gross1-47/+49
Instead of using a function local static e820 map in xen_memory_setup() and calling various functions in the same source with the map as a parameter use a map directly accessible by all functions in the source. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: David Vrabel <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: eliminate scalability issues from initial mapping setupJuergen Gross3-39/+156
Direct Xen to place the initial P->M table outside of the initial mapping, as otherwise the 1G (implementation) / 2G (theoretical) restriction on the size of the initial mapping limits the amount of memory a domain can be handed initially. As the initial P->M table is copied rather early during boot to domain private memory and it's initial virtual mapping is dropped, the easiest way to avoid virtual address conflicts with other addresses in the kernel is to use a user address area for the virtual address of the initial P->M table. This allows us to just throw away the page tables of the initial mapping after the copy without having to care about address invalidation. It should be noted that this patch won't enable a pv-domain to USE more than 512 GB of RAM. It just enables it to be started with a P->M table covering more memory. This is especially important for being able to boot a Dom0 on a system with more than 512 GB memory. Signed-off-by: Juergen Gross <[email protected]> Based-on-patch-by: Jan Beulich <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: don't build mfn tree if tools don't need itJuergen Gross1-3/+7
In case the Xen tools indicate they don't need the p2m 3 level tree as they support the virtual mapped linear p2m list, just omit building the tree. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: David Vrabel <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: save linear p2m list address in shared info structureJuergen Gross1-0/+17
The virtual address of the linear p2m list should be stored in the shared info structure read by the Xen tools to be able to support 64 bit pv-domains larger than 512 GB. Additionally the linear p2m list interface includes a generation count which is changed prior to and after each mapping change of the p2m list. Reading the generation count the Xen tools can detect changes of the mappings and re-read the p2m list eventually. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: David Vrabel <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen: sync with xen headersJuergen Gross2-24/+107
Use the newest headers from the xen tree to get some new structure layouts. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: David Vrabel <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20arm/xen: Drop the definition of xen_pci_platform_unplugJulien Grall1-3/+0
The commit 6f6c15ef912465b3aaafe709f39bd6026a8b3e72 "xen/pvhvm: Remove the xen_platform_pci int." makes the x86 version of xen_pci_platform_unplug static. Therefore we don't need anymore to define a dummy xen_pci_platform_unplug for ARM. Signed-off-by: Julien Grall <[email protected]> Signed-off-by: Stefano Stabellini <[email protected]>
2015-08-20xen/events: Support event channel rebind on ARMJulien Grall6-10/+24
Currently, the event channel rebind code is gated with the presence of the vector callback. The virtual interrupt controller on ARM has the concept of per-CPU interrupt (PPI) which allow us to support per-VCPU event channel. Therefore there is no need of vector callback for ARM. Xen is already using a free PPI to notify the guest VCPU of an event. Furthermore, the xen code initialization in Linux (see arch/arm/xen/enlighten.c) is requesting correctly a per-CPU IRQ. Introduce new helper xen_support_evtchn_rebind to allow architecture decide whether rebind an event is support or not. It will always return true on ARM and keep the same behavior on x86. This is also allow us to drop the usage of xen_have_vector_callback entirely in the ARM code. Signed-off-by: Julien Grall <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen-blkfront: convert to blk-mq APIsBob Liu1-86/+60
Note: This patch is based on original work of Arianna's internship for GNOME's Outreach Program for Women. Only one hardware queue is used now, so there is no significant performance change The legacy non-mq code is deleted completely which is the same as other drivers like virtio, mtip, and nvme. Also dropped one unnecessary holding of info->io_lock when calling blk_mq_stop_hw_queues(). Signed-off-by: Arianna Avanzini <[email protected]> Signed-off-by: Bob Liu <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Jens Axboe <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20xen/preempt: use need_resched() instead of should_resched()Konstantin Khlebnikov1-1/+1
This code is used only when CONFIG_PREEMPT=n and only in non-atomic context: xen_in_preemptible_hcall is set only in privcmd_ioctl_hypercall(). Thus preempt_count is zero and should_resched() is equal to need_resched(). Signed-off-by: Konstantin Khlebnikov <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-20x86/xen: fix non-ANSI declaration of xen_has_pv_devices()Colin Ian King1-1/+1
xen_has_pv_devices() has no parameters, so use the normal void parameter convention to make it match the prototype in the header file include/xen/platform_pci.h. Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-08-16Linux 4.2-rc7Linus Torvalds1-1/+1
2015-08-16Merge tag 'armsoc-for-linus' of ↵Linus Torvalds13-56/+79
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "A smallish batch of fixes, a little more than expected this late, but all fixes are contained to their platforms and seem reasonably low risk: - a somewhat large SMP fix for ux500 that still seemed warranted to include here - OMAP DT fixes for pbias regulator specification that broke due to some DT reshuffling - PCIe IRQ routing bugfix for i.MX - networking fixes for keystone - runtime PM for OMAP GPMC - a couple of error path bug fixes for exynos" * tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: dts: keystone: Fix the mdio bindings by moving it to soc specific file ARM: dts: keystone: fix the clock node for mdio memory: omap-gpmc: Don't try to save uninitialized GPMC context ARM: imx6: correct i.MX6 PCIe interrupt routing ARM: ux500: add an SMP enablement type and move cpu nodes ARM: dts: dra7: Fix broken pbias device creation ARM: dts: OMAP5: Fix broken pbias device creation ARM: dts: OMAP4: Fix broken pbias device creation ARM: dts: omap243x: Fix broken pbias device creation ARM: EXYNOS: fix double of_node_put() on error path ARM: EXYNOS: Fix potentian kfree() of ro memory
2015-08-16Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds2-2/+2
Pull MIPS bugfix from Ralf Baechle: "Only a single MIPS fix - the math when invoking syscall_trace_enter was wrong" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: Fix seccomp syscall argument for MIPS64
2015-08-16Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds4-9/+22
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Merge x86 fixes from Ingo Molnar: "Two followup fixes related to the previous LDT fix" Also applied a further FPU emulation fix from Andy Lutomirski to the branch before actually merging it. * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip x86/ldt: Further fix FPU emulation x86/ldt: Correct FPU emulation access to LDT x86/ldt: Correct LDT access in single stepping logic
2015-08-16x86/ldt: Further fix FPU emulationAndy Lutomirski1-1/+1
The previous fix confused a selector with a segment prefix. Fix it. Compile-tested only. Cc: [email protected] Cc: Juergen Gross <[email protected]> Reported-by: Linus Torvalds <[email protected]> Fixes: 4809146b86c3 ("x86/ldt: Correct FPU emulation access to LDT") Signed-off-by: Andy Lutomirski <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-08-16fs/fuse: fix ioctl type confusionJann Horn1-1/+9
fuse_dev_ioctl() performed fuse_get_dev() on a user-supplied fd, leading to a type confusion issue. Fix it by checking file->f_op. Signed-off-by: Jann Horn <[email protected]> Acked-by: Miklos Szeredi <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-08-16Merge tag 'keystone-dts-late-fixes-v2' of ↵Olof Johansson4-20/+33
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone into fixes ARM: Couple of Keysyone MDIO DTS fixes for 4.2-rc6+ These are necessary to get the NIC card working on all Keystone EVMs. Couple of boards are broken without these two fixes. * tag 'keystone-dts-late-fixes-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone: ARM: dts: keystone: Fix the mdio bindings by moving it to soc specific file ARM: dts: keystone: fix the clock node for mdio Signed-off-by: Olof Johansson <[email protected]>
2015-08-16MIPS: Fix seccomp syscall argument for MIPS64Markos Chandras2-2/+2
Commit 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls (o32)") fixed indirect system calls on O32 but it also introduced a bug for MIPS64 where it erroneously modified the v0 (syscall) register with the assumption that the sycall offset hasn't been taken into consideration. This breaks seccomp on MIPS64 n64 and n32 ABIs. We fix this by replacing the addition with a move instruction. Fixes: 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls (o32)") Cc: <[email protected]> # 3.15+ Reviewed-by: James Hogan <[email protected]> Signed-off-by: Markos Chandras <[email protected]> Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/10951/ Signed-off-by: Ralf Baechle <[email protected]>
2015-08-15Merge tag 'scsi-fixes' of ↵Linus Torvalds5-34/+28
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "This has two libfc fixes for bugs causing rare crashes, one iscsi fix for a potential hang on shutdown, and a fix for an I/O blocksize issue which caused a regression" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: sd: Fix maximum I/O size for BLOCK_PC requests libfc: Fix fc_fcp_cleanup_each_cmd() libfc: Fix fc_exch_recv_req() error path libiscsi: Fix host busy blocking during connection teardown
Powered by cgit, Gruvboxed by Blaster4385.