aboutsummaryrefslogtreecommitdiffstats
path: root/xen
Commit message (Collapse)AuthorAgeFilesLines
...
* xsm: clean up unneeded current referencesDaniel De Graaf2013-10-041-2/+2
| | | | | | | | | | | | Some XSM hooks in dummy.h used current->domain when this was also passed as a parameter; use the parameter in these cases. There are two hooks where this does not apply and which are not immediately obvious: xsm_set_target's parameters are the device model and HVM domains, and xsm_mem_sharing_op's first parameter is the source of the shared page, not the domain making the hypercall. Reported-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
* xsm: forbid PV guest console readsDaniel De Graaf2013-10-041-3/+3
| | | | | | | | The CONSOLEIO_read operation was incorrectly allowed to PV guests if the hypervisor was compiled in debug mode (with VERBOSE defined). Reported-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
* x86: make hvm_cpuid() tolerate NULL pointersJan Beulich2013-10-043-19/+29
| | | | | | | | | | | Now that other HVM code started making more extensive use of hvm_cpuid(), let's not force every caller to declare dummy variables for output not cared about. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Jun Nakajima <jun.nakajima@intel.com>
* Nested VMX: fix IA32_VMX_CR4_FIXED1 msr emulationYang Zhang2013-10-043-4/+53
| | | | | | | | | | | | | Currently, it use hardcode value for IA32_VMX_CR4_FIXED1. This is wrong. We should check guest's cpuid to know which bits are writeable in CR4 by guest and allow the guest to set the corresponding bit only when guest has the feature. Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com> Cleanup. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Jun Nakajima <jun.nakajima@intel.com>
* VMX: clean up capability checksJan Beulich2013-10-042-19/+35
| | | | | | | | | | | | VMCS size validation on APs should check against BP's size. No need for a separate cpu_has_vmx_ins_outs_instr_info variable anymore. Use proper symbolics. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Jun Nakajima <jun.nakajima@intel.com>
* Nested VMX: check VMX capability before read VMX related MSRsYang Zhang2013-10-043-0/+26
| | | | | | | | | | | | VMX MSRs only available when the CPU support the VMX feature. In addition, VMX_TRUE* MSRs only available when bit 55 of VMX_BASIC MSR is set. Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com> Cleanup. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Jun Nakajima <jun.nakajima@intel.com>
* x86/percpu: Force INVALID_PERCPU_AREA into the non-canonical address regionAndrew Cooper2013-10-041-1/+8
| | | | | | | | | | | | | This causes accidental uses of per_cpu() on a pcpu with an INVALID_PERCPU_AREA to result in a #GF for attempting to access the middle of the non-canonical virtual address region. This is preferable to the current behaviour, where incorrect use of per_cpu() will result in an effective NULL structure dereference which has security implication in the context of PV guests. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Keir Fraser <keir@xen.org>
* x86/idle: Fix get_cpu_idle_time()'s interaction with offline pcpusAndrew Cooper2013-10-042-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Checking for "idle_vcpu[cpu] != NULL" is insufficient protection against offline pcpus. From a hypercall, vcpu_runstate_get() will determine "v != current", and try to take the vcpu_schedule_lock(). This will try to look up per_cpu(schedule_data, v->processor) and promptly suffer a NULL structure deference as v->processors' __per_cpu_offset is INVALID_PERCPU_AREA. One example might look like this: ... Xen call trace: [<ffff82c4c0126ddb>] vcpu_runstate_get+0x50/0x113 [<ffff82c4c0126ec6>] get_cpu_idle_time+0x28/0x2e [<ffff82c4c012b5cb>] do_sysctl+0x3db/0xeb8 [<ffff82c4c023280d>] compat_hypercall+0xbd/0x116 Pagetable walk from 0000000000000040: L4[0x000] = 0000000186df8027 0000000000028207 L3[0x000] = 0000000188e36027 00000000000261c9 L2[0x000] = 0000000000000000 ffffffffffffffff **************************************** Panic on CPU 11: ... get_cpu_idle_time() has been updated to correctly deal with offline pcpus itself by returning 0, in the same way as it would if it was missing the idle_vcpu[] pointer. In doing so, XENPF_getidletime needed updating to correctly retain its described behaviour of clearing bits in the cpumap for offline pcpus. As this crash can only be triggered with toolstack hypercalls, it is not a security issue and just a simple bug. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Keir Fraser <keir@xen.org>
* xen/arm: map_domain_page: reuse slots with avail == 0Stefano Stabellini2013-10-031-7/+10
| | | | | | | | If a slot has avail == 0 but still points to the right mfn, reuse it. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Tim Deegan <tim@xen.org> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* xen/arm32: don't export v7_initJulien Grall2013-10-031-1/+1
| | | | | Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* x86: don't blindly create L3 tables for the direct mapJan Beulich2013-09-304-28/+20
| | | | | | | | | | | | Now that the direct map area can extend all the way up to almost the end of address space, this is wasteful. Also fold two almost redundant messages in SRAT parsing into one. Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Malcolm Crossley <malcolm.crossley@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Keir Fraser <keir@xen.org>
* x86: properly set up fbld emulation operand addressJan Beulich2013-09-301-2/+2
| | | | | | | This is CVE-2013-4361 / XSA-66. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
* x86/mm/shadow: Fix initialization of PV shadow L4 tables.Tim Deegan2013-09-301-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Shadowed PV L4 tables must have the same Xen mappings as their unshadowed equivalent. This is done by copying the Xen entries verbatim from the idle pagetable, and then using guest_l4_slot() in the SHADOW_FOREACH_L4E() iterator to avoid touching those entries. adc5afbf1c70ef55c260fb93e4b8ce5ccb918706 (x86: support up to 16Tb) changed the definition of ROOT_PAGETABLE_XEN_SLOTS to extend right to the top of the address space, which causes the shadow code to copy Xen mappings into guest-kernel-address slots too. In the common case, all those slots are zero in the idle pagetable, and no harm is done. But if any slot above #271 is non-zero, Xen will crash when that slot is later cleared (it attempts to drop shadow-pagetable refcounts on its own L4 pagetables). Fix by using the new ROOT_PAGETABLE_PV_XEN_SLOTS when appropriate. Monitor pagetables need the full Xen mappings, so they keep using the old name (with its new semantics). This is CVE-2013-4356 / XSA-64. Signed-off-by: Tim Deegan <tim@xen.org> Reviewed-by: Jan Beulich <jbeulich@suse.com>
* x86: properly handle hvm_copy_from_guest_{phys,virt}() errorsJan Beulich2013-09-304-31/+66
| | | | | | | | | | | | Ignoring them generally implies using uninitialized data and, in all but two of the cases dealt with here, potentially leaking hypervisor stack contents to guests. This is CVE-2013-4355 / XSA-63. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Tim Deegan <tim@xen.org> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
* x86/AMD-Vi: Fix IVRS HPET special->handle overrideSuravee Suthikulpanit2013-09-303-15/+32
| | | | | | | | | | | | | The current logic does not handle the case when HPET special->handle is invalid in IVRS. On such system, the following message is shown: (XEN) AMD-Vi: Failed to setup HPET MSI remapping: Wrong HPET This patch will allow the ivrs_hpet[<handle>]=<sbdf> to override the IVRS. Also, it removes struct hpet_sbdf.iommu since it is not used anywhere in the code. Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* cpupools: update domU's node-affinity on the cpupool_unassign_cpu() pathDario Faggioli2013-09-301-0/+6
| | | | | | | | | that is, when a cpu is remove from a pool, as it is happening already on the cpupool_assign_cpu_*() path (i.e., when a cpu is added to a pool). Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
* Nested VMX: Expose unrestricted guest feature to guestYang Zhang2013-09-302-1/+5
| | | | | | | | With virtual unrestricted guest feature, L2 guest is allowed to run with PG cleared. Also, allow PAE not set during virtual vmexit emulation. Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com> Acked-by: Eddie.Dong@intel.com
* xen: arm: move smp_init_cpus to smpboot.cIan Campbell2013-09-273-125/+127
| | | | | | | Seems like a better home. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Julien Grall <julien.grall@linaro.org>
* xen: arm: split cpu0's domheap mapping PTs out from xen_secondIan Campbell2013-09-271-18/+17
| | | | | | | | Now that bringup has been rewritten we don't need these 4 contiguous pages for the 1:1 map. So split them out and only allocate them for 32 bit Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
* xen: arm: configure TCR_EL2 for 40 bit physical address spaceIan Campbell2013-09-271-2/+2
| | | | | | Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Julien Grall <julien.grall@linaro.org> Acked-by: Tim Deegan <tim@xen.org>
* xen: arm: use symbolic names for MPIDR bits.Ian Campbell2013-09-273-9/+11
| | | | | | | | arm32 already uses MPIDR_HWID_MASK, use it on arm64 too. Add MPIDR_{SMP,UP} (and bitwise equivalents) and use them. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
* xen: arm: rewrite start of day page table and cpu bring upIan Campbell2013-09-2713-675/+679
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is unfortunately a rather large monolithic patch. Rather than bringing up all CPUs in lockstep as we setup paging and relocate Xen instead create a simplified set of dedicated boot time pagetables. This allows secondary CPUs to remain powered down or in the firmware until we actually want to enable them. The bringup is now done later on in C and can be driven by DT etc. I have included code for the vexpress platform, but other platforms will need to be added. The mechanism for deciding how to bring up a CPU differs between arm32 and arm64. On arm32 it is essentially a per-platform property, with the exception of PSCI which can be implemented globally (but isn't here). On arm64 there is a per-cpu property in the device tree. Secondary CPUs are brought up directly into the relocated Xen image, instead of relying on being able to launch on the unrelocated Xen and hoping that it hasn't been clobbered. As part of this change drop support for switching from secure mode to NS HYP as well as the early CPU kick. Xen now requires that it is launched in NS HYP mode and that firmware configure things such that secondary CPUs can be woken up by a primarly CPU in HYP mode. This may require fixes to bootloaders or the use of a boot wrapper. The changes done here (re)exposed an issue with relocating Xen and the compiler spilling values to the stack between the copy and the actual switch to the relocaed copy of Xen in setup_pagetables. Therefore switch to doing the copy and switch in a single asm function where we can control precisely what gets spilled to the stack etc. Since we now have a separate set of boot pagetables it is much easier to build the real Xen pagetables inplace before relocating rather than the more complex approach of rewriting the pagetables in the relocated copy before switching. This will also enable Xen to be loaded above the 4GB boundary on 64-bit. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org> Acked-by: Julien Grall <julien.grall@linaro.org>
* xen: arm: implement smp initialisation callbacks for exynos5Ian Campbell2013-09-271-0/+31
| | | | | | | | These were removed in "xen: arm: rewrite start of day page table and cpu bring up". Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Reviewed-by: Julien Grall <julien.grall@linaro.org>
* xen: arm: implement arch/platform SMP and CPU initialisation frameworkIan Campbell2013-09-2710-1/+196
| | | | | | | | | | | | Includes an implementation for vexpress using the sysflags interface and support for the ARMv8 "spin-table" method. Unused until "rewrite start of day page table and cpu bring up", split out to simplify review. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org> Acked-by: Julien Grall <julien.grall@linaro.org>
* xen: arm: add two new device tree helpersIan Campbell2013-09-272-0/+46
| | | | | | | | - dt_property_read_u64 - dt_find_node_by_type Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Julien Grall <julien.grall@linaro.org>
* xen: arm: make sure we stay within the memory bank during mm setupIan Campbell2013-09-271-3/+10
| | | | | | | | | | Otherwise if there is a module in another bank we can run off the end. Rename *n to *end to make it clearer what is happening. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org> Acked-by: Julien Grall <julien.grall@linaro.org>
* xen: arm: Log the raw MIDR on boot.Ian Campbell2013-09-271-2/+3
| | | | | | Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Julien Grall <julien.grall@linaro.org> Acked-by: Tim Deegan <tim@xen.org>
* xen: arm: build platform support only on the relevant archIan Campbell2013-09-271-3/+3
| | | | | | | | | | midway, omap5 and exynos are all 32-bit only platforms. This avoids needing CONFIG_ARM_32 ifdefs around the SMP callbacks on such platforms. Vexpress is both. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Julien Grall <julien.grall@linaro.org>
* xen: arm: Load xen under 4GB on 32-bitIan Campbell2013-09-271-0/+8
| | | | | | | | We need to be able to use a 1:1 mapping during bring up. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Julien Grall <julien.grall@linaro.org> Acked-by: Tim Deegan <tim@xen.org>
* x86/microcode: Check whether the microcode is correctKonrad Rzeszutek Wilk2013-09-271-1/+16
| | | | | | | | | | | | | | | We do the microcode code update in two steps - the presmp: 'microcode_presmp_init' and when CPUs are brought up: 'microcode_init'. The earlier performs the microcode update on the BSP - but unfortunately it does not check whether the update failed. Which means that we might try later to update a incorrect payload on the rest of CPUs. This patch handles this odd situation. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Keir Fraser <keir@xen.org>
* x86/microcode: Scan the initramfs payload for microcode blobKonrad Rzeszutek Wilk2013-09-274-16/+309
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Linux kernel is able to update the microcode during early bootup via inspection of the initramfs blob to see if there is an cpio image with certain microcode files. Linux is able to function with two (or more) cpio archives in the initrd b/c it unpacks all of the cpio archives. The format of the early initramfs is nicely documented in Linux's Documentation/x86/early-microcode.txt: Early load microcode ==================== By Fenghua Yu <fenghua.yu@intel.com> Kernel can update microcode in early phase of boot time. Loading microcode early can fix CPU issues before they are observed during kernel boot time. Microcode is stored in an initrd file. The microcode is read from the initrd file and loaded to CPUs during boot time. The format of the combined initrd image is microcode in cpio format followed by the initrd image (maybe compressed). Kernel parses the combined initrd image during boot time. The microcode file in cpio name space is: kernel/x86/microcode/GenuineIntel.bin During BSP boot (before SMP starts), if the kernel finds the microcode file in the initrd file, it parses the microcode and saves matching microcode in memory. If matching microcode is found, it will be uploaded in BSP and later on in all APs. The cached microcode patch is applied when CPUs resume from a sleep state. There are two legacy user space interfaces to load microcode, either through /dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file in sysfs. In addition to these two legacy methods, the early loading method described here is the third method with which microcode can be uploaded to a system's CPUs. The following example script shows how to generate a new combined initrd file in /boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and original initrd image /boot/initrd-3.5.0.img. mkdir initrd cd initrd mkdir kernel mkdir kernel/x86 mkdir kernel/x86/microcode cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin find .|cpio -oc >../ucode.cpio cd .. cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img As such this code inspects the initrd to see if the microcode signatures are present and if so updates the hypervisor. The option to turn this scan on/off is gated by the 'ucode' parameter. The options are now: 'scan' Scan for the microcode in any multiboot payload. <index> Attempt to load microcode blob (not the cpio archive format) from the multiboot payload number. This option alters slightly the 'ucode' parameter by only allowing either parameter: ucode=[<index>|scan] Implementation wise the ucode_blob is defined as __initdata. That is OK from the viewpoint of suspend/resume as the the underlaying architecture microcode (microcode_intel or microcode_amd) end up saving the blob in 'struct ucode_cpu_info' which is a per-cpu data structure (see ucode_cpu_info). They end up saving it when doing the pre-SMP (for CPU0) and SMP (for the rest) microcode loading. Naturally if one does a hypercall to update the microcode and it is newer, then the old per-cpu data is replaced. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Keir Fraser <keir@xen.org>
* AMD IOMMU: fix Dom0 device setup failure for host bridgesSuravee Suthikulpanit2013-09-275-5/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The host bridge device (i.e. 0x18 for AMD) does not require IOMMU, and therefore is not included in the IVRS. The current logic tries to map all PCI devices to an IOMMU. In this case, "xl dmesg" shows the following message on AMD sytem. (XEN) setup 0000:00:18.0 for d0 failed (-19) (XEN) setup 0000:00:18.1 for d0 failed (-19) (XEN) setup 0000:00:18.2 for d0 failed (-19) (XEN) setup 0000:00:18.3 for d0 failed (-19) (XEN) setup 0000:00:18.4 for d0 failed (-19) (XEN) setup 0000:00:18.5 for d0 failed (-19) This patch adds a new device type (i.e. DEV_TYPE_PCI_HOST_BRIDGE) which corresponds to PCI class code 0x06 and sub-class 0x00. Then, it uses this new type to filter when trying to map device to IOMMU. Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Reported-by: Stefan Bader <stefan.bader@canonical.com> On VT-d refuse (un)mapping host bridges for other than the hardware domain. Coding style cleanup. Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
* xen: support RAM at addresses 0 and 4096Ian Campbell2013-09-261-3/+3
| | | | | | | | | | | | | | Currently the mapping from pages to zones causes the page at zero to go into zone -1 and the page at 4096 to go into zone 0, which is the Xen zone (confusing various assertions). Arrange instead for the mapping to be such that zone 0 is always reserved for Xen and all other pages map to a zone >= 1. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Keir Fraser <keir@xen.org> Cc: jbeulich@suse.com Acked-by: Tim Deegan <tim@xen.org>
* xen/arm: print the location of the Xen heap on 32 bitIan Campbell2013-09-261-2/+4
| | | | | | Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Reviewed-by: Julien Grall <julien.grall@linaro.org> Acked-by: Tim Deegan <tim@xen.org>
* xen/arm: rename boot misc region to boot reloc now it has a single purposeIan Campbell2013-09-262-7/+4
| | | | | | Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Julien Grall <julien.grall@linaro.org> Acked-by: Tim Deegan <tim@xen.org>
* xen/arm: Support dtb /memreserve/ regionsIan Campbell2013-09-267-11/+90
| | | | | | | | | | | | | This requires a mapping of the DTB during setup_mm. Previously this was in the BOOT_MISC slot, which is clobbered by setup_pagetables. Split it out into its own slot which can be preserved. Also handle these regions as part of consider_modules() and when adding pages to the heaps to ensure we do not locate any part of Xen or the heaps over them. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
* xen/arm: cope with modules outside of "visible" RAMIan Campbell2013-09-261-0/+6
| | | | | | | | | This can happen if modules are in a bank which we can't cope with e.g. due to being non-contiguous. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Reviewed-by: Julien Grall <julien.grall@linaro.org> Acked-by: Tim Deegan <tim@xen.org>
* xen/arm: do not relocate Xen outside of visible RAMIan Campbell2013-09-261-1/+9
| | | | | | | | | Since we do not handle non-contiguous banks of memory lets avoid relocating Xen into such a bank. Avoids issues such as free_init_memory releasing pages which are outside of the frametable. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
* xen/arm: Reserve FDT via early module mechanismIan Campbell2013-09-263-8/+17
| | | | | | | | | | This will stop us putting any heaps or relocating Xen itself over the FDT. The devicetree will be copied to allocated memory in setup_mm and the original copy will be freed by discard_initial_modules. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
* xen/arm: DOMHEAP_SECOND_PAGES is arm32 specificIan Campbell2013-09-261-3/+3
| | | | | | | | since 5263507b1b4a "xen: arm: Use a direct mapping of RAM on arm64" Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Julien Grall <julien.grall@linaro.org> Acked-by: Tim Deegan <tim@xen.org>
* xen/arm: ensure the xenheap is 32MB alignedIan Campbell2013-09-261-1/+2
| | | | | | | | | | | | My patch 08693f5948d8 "xen: arm: reduce the size of the xen heap to max 1/8 RAM size" unintentionally violated the constraint that the xenheap must be 32MB aligned, since we only explicitly align the end of the heap and xenheap_pages was not a multiple of 32 pages. Round xenheap pages up to a 32MB boundary. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
* xen/arm: Don't dump stack when the VCPU is offlineJulien Grall2013-09-261-0/+6
| | | | | | | | When a VCPU is not yet online, the registers contain garbagge. This will result to call randomly BUG() in show_guest_stack. Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* xen: arm: use new 64-bit zImage magic numbers for Xen binaryIan Campbell2013-09-261-0/+8
| | | | | | | | | | | | | Upstream commit 4370eec05a88 "arm64: Expand arm64 image header" ended up changing the zImage magic (which was actually the initial branch instructio encoding!). The new header has a proper magic number at a fixed location. Switch Xen itself to using this format. Neither the bootwrapper nor the models care about this header themselves and real bootloaders are not widely used, so now is as good a time as any to switch (as upstream have proven) Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
* xen: arm: handle new 64-bit zImage magic numbersIan Campbell2013-09-261-3/+10
| | | | | | | | | Upstream commit 4370eec05a88 "arm64: Expand arm64 image header" ended up changing the zImage magic (which was actually the initial branch instruction encoding!). The new header has a proper magic number at a fixed location. Support that as well as the original magic. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
* xen/arm: Use the hardware ID to boot correctly secondary cpusJulien Grall2013-09-262-5/+10
| | | | | | | | | Secondary CPUs will spin in head.S until their MPIDR[23:0] correspond to the smp_up_cpu. Actually Xen will set the value with the logical CPU ID which is wrong. Use the cpu_logical_map to get the correct CPU ID. Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* xen/arm: Dissociate logical and hardware CPU IDJulien Grall2013-09-264-49/+119
| | | | | | | | | | | Introduce cpu_logical_map to associate a logical CPU ID to an hardware CPU ID. This map will be filled during Xen boot via the device tree. Each CPU node contains a "reg" property which contains the hardware ID (ie MPIDR[0:23]). Also move /cpus parsing later so we can use the dt_* API. Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* xen/arm: Fix assert in send_SGI_oneJulien Grall2013-09-261-1/+1
| | | | | | | The GIC can handle maximum 8 cpus (0...7). The CPU id 7 is still valid. Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* xen/arm: gic: Use the correct CPU IDJulien Grall2013-09-261-8/+37
| | | | | | | | | | | | | The GIC mapping of CPU interfaces does not necessarily match the logical CPU numbering. When Xen wants to send an SGI to specific CPU, it needs to use the GIC CPU ID. It can be retrieved from ITARGETSR0, in fact when this field is read, the GIC will return a value that corresponds only to the processor reading the register. So Xen can use the PPI 0 to initialize the mapping. Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* xen/arm: Initialize correctly IRQ routingJulien Grall2013-09-261-1/+2
| | | | | | | | | | | | When Xen initialize the GIC distributor, we need to route all the IRQs to the boot CPU. The CPU ID can differ between Xen and the GIC. When ITARGETSR0 is read, each field will return a value that corresponds only to the processor reading the register. So Xen can use the PPI 0 to initialize correctly the routing. Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* xen/arm: use cpumask_t to describe cpu mask in gic_route_dt_irqJulien Grall2013-09-263-12/+17
| | | | | | | Replace by cpumask_t to take advantage of cpumask_* helpers. Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-07 23:52:38 +0000