aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/call-graph-from-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2017-05-19xen: make xen_flush_tlb_all() staticJuergen Gross1-1/+1
xen_flush_tlb_all() is used in arch/x86/xen/mmu.c only. Make it static. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-19xen: cleanup pvh leftovers from pv-only sourcesJuergen Gross2-75/+42
There are some leftovers testing for pvh guest mode in pv-only source files. Remove them. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-18xen/9pfs: p9_trans_xen_init and p9_trans_xen_exit can be staticWei Yongjun1-2/+2
Fixes the following sparse warnings: net/9p/trans_xen.c:528:5: warning: symbol 'p9_trans_xen_init' was not declared. Should it be static? net/9p/trans_xen.c:540:6: warning: symbol 'p9_trans_xen_exit' was not declared. Should it be static? Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2017-05-18xen/9pfs: fix return value check in xen_9pfs_front_probe()Wei Yongjun1-2/+2
In case of error, the function xenbus_read() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2017-05-11xen: adjust early dom0 p2m handling to xen hypervisor behaviorJuergen Gross1-3/+4
When booted as pv-guest the p2m list presented by the Xen is already mapped to virtual addresses. In dom0 case the hypervisor might make use of 2M- or 1G-pages for this mapping. Unfortunately while being properly aligned in virtual and machine address space, those pages might not be aligned properly in guest physical address space. So when trying to obtain the guest physical address of such a page pud_pfn() and pmd_pfn() must be avoided as those will mask away guest physical address bits not being zero in this special case. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-11x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under XenJuergen Gross2-3/+3
When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set on AMD cpus. This bug/feature bit is kind of special as it will be used very early when switching threads. Setting the bit and clearing it a little bit later leaves a critical window where things can go wrong. This time window has enlarged a little bit by using setup_clear_cpu_cap() instead of the hypervisor's set_cpu_features callback. It seems this larger window now makes it rather easy to hit the problem. The proper solution is to never set the bit in case of Xen. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-05xen/x86: Do not call xen_init_time_ops() until shared_info is initializedBoris Ostrovsky2-3/+8
Routines that are set by xen_init_time_ops() use shared_info's pvclock_vcpu_time_info area. This area is not properly available until shared_info is mapped in xen_setup_shared_info(). This became especially problematic due to commit dd759d93f4dd ("x86/timers: Add simple udelay calibration") where we end up reading tsc_to_system_mul from xen_dummy_shared_info (i.e. getting zero value) and then trying to divide by it in pvclock_tsc_khz(). Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-05x86/xen: fix xsave capability settingJuergen Gross1-23/+9
Commit 690b7f10b4f9f ("x86/xen: use capabilities instead of fake cpuid values for xsave") introduced a regression as it tried to make use of the fixup feature before it being available. Fall back to the old variant testing via cpuid(). Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-03xen: Move xen_have_vector_callback definition to enlighten.cBoris Ostrovsky2-3/+3
Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c. Since guest-type-neutral code refers to this variable this causes build failures when CONFIG_XEN_PVHVM is not defined. Moving xen_have_vector_callback definition to enlighten.c resolves this issue. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reported-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02xen: Implement EFI reset_system callbackJulien Grall4-2/+23
When rebooting DOM0 with ACPI on ARM64, the kernel is crashing with the stack trace [1]. This is happening because when EFI runtimes are enabled, the reset code (see machine_restart) will first try to use EFI restart method. However, the EFI restart code is expecting the reset_system callback to be always set. This is not the case for Xen and will lead to crash. The EFI restart helper is used in multiple places and some of them don't not have fallback (see machine_power_off). So implement reset_system callback as a call to xen_reboot when using EFI Xen. [ 36.999270] reboot: Restarting system [ 37.002921] Internal error: Attempting to execute userspace memory: 86000004 [#1] PREEMPT SMP [ 37.011460] Modules linked in: [ 37.014598] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.11.0-rc1-00003-g1e248b60a39b-dirty #506 [ 37.023903] Hardware name: (null) (DT) [ 37.027734] task: ffff800902068000 task.stack: ffff800902064000 [ 37.033739] PC is at 0x0 [ 37.036359] LR is at efi_reboot+0x94/0xd0 [ 37.040438] pc : [<0000000000000000>] lr : [<ffff00000880f2c4>] pstate: 404001c5 [ 37.047920] sp : ffff800902067cf0 [ 37.051314] x29: ffff800902067cf0 x28: ffff800902068000 [ 37.056709] x27: ffff000008992000 x26: 000000000000008e [ 37.062104] x25: 0000000000000123 x24: 0000000000000015 [ 37.067499] x23: 0000000000000000 x22: ffff000008e6e250 [ 37.072894] x21: ffff000008e6e000 x20: 0000000000000000 [ 37.078289] x19: ffff000008e5d4c8 x18: 0000000000000010 [ 37.083684] x17: 0000ffffa7c27470 x16: 00000000deadbeef [ 37.089079] x15: 0000000000000006 x14: ffff000088f42bef [ 37.094474] x13: ffff000008f42bfd x12: ffff000008e706c0 [ 37.099870] x11: ffff000008e70000 x10: 0000000005f5e0ff [ 37.105265] x9 : ffff800902067a50 x8 : 6974726174736552 [ 37.110660] x7 : ffff000008cc6fb8 x6 : ffff000008cc6fb0 [ 37.116055] x5 : ffff000008c97dd8 x4 : 0000000000000000 [ 37.121453] x3 : 0000000000000000 x2 : 0000000000000000 [ 37.126845] x1 : 0000000000000000 x0 : 0000000000000000 [ 37.132239] [ 37.133808] Process systemd-shutdow (pid: 1, stack limit = 0xffff800902064000) [ 37.141118] Stack: (0xffff800902067cf0 to 0xffff800902068000) [ 37.146949] 7ce0: ffff800902067d40 ffff000008085334 [ 37.154869] 7d00: 0000000000000000 ffff000008f3b000 ffff800902067d40 ffff0000080852e0 [ 37.162787] 7d20: ffff000008cc6fb0 ffff000008cc6fb8 ffff000008c7f580 ffff000008c97dd8 [ 37.170706] 7d40: ffff800902067d60 ffff0000080e2c2c 0000000000000000 0000000001234567 [ 37.178624] 7d60: ffff800902067d80 ffff0000080e2ee8 0000000000000000 ffff0000080e2df4 [ 37.186544] 7d80: 0000000000000000 ffff0000080830f0 0000000000000000 00008008ff1c1000 [ 37.194462] 7da0: ffffffffffffffff 0000ffffa7c4b1cc 0000000000000000 0000000000000024 [ 37.202380] 7dc0: ffff800902067dd0 0000000000000005 0000fffff24743c8 0000000000000004 [ 37.210299] 7de0: 0000fffff2475f03 0000000000000010 0000fffff2474418 0000000000000005 [ 37.218218] 7e00: 0000fffff2474578 000000000000000a 0000aaaad6b722c0 0000000000000001 [ 37.226136] 7e20: 0000000000000123 0000000000000038 ffff800902067e50 ffff0000081e7294 [ 37.234055] 7e40: ffff800902067e60 ffff0000081e935c ffff800902067e60 ffff0000081e9388 [ 37.241973] 7e60: ffff800902067eb0 ffff0000081ea388 0000000000000000 00008008ff1c1000 [ 37.249892] 7e80: ffffffffffffffff 0000ffffa7c4a79c 0000000000000000 ffff000000020000 [ 37.257810] 7ea0: 0000010000000004 0000000000000000 0000000000000000 ffff0000080830f0 [ 37.265729] 7ec0: fffffffffee1dead 0000000028121969 0000000001234567 0000000000000000 [ 37.273651] 7ee0: ffffffffffffffff 8080000000800000 0000800000008080 feffa9a9d4ff2d66 [ 37.281567] 7f00: 000000000000008e feffa9a9d5b60e0f 7f7fffffffff7f7f 0101010101010101 [ 37.289485] 7f20: 0000000000000010 0000000000000008 000000000000003a 0000ffffa7ccf588 [ 37.297404] 7f40: 0000aaaad6b87d00 0000ffffa7c4b1b0 0000fffff2474be0 0000aaaad6b88000 [ 37.305326] 7f60: 0000fffff2474fb0 0000000001234567 0000000000000000 0000000000000000 [ 37.313240] 7f80: 0000000000000000 0000000000000001 0000aaaad6b70d4d 0000000000000000 [ 37.321159] 7fa0: 0000000000000001 0000fffff2474ea0 0000aaaad6b5e2e0 0000fffff2474e80 [ 37.329078] 7fc0: 0000ffffa7c4b1cc 0000000000000000 fffffffffee1dead 000000000000008e [ 37.336997] 7fe0: 0000000000000000 0000000000000000 9ce839cffee77eab fafdbf9f7ed57f2f [ 37.344911] Call trace: [ 37.347437] Exception stack(0xffff800902067b20 to 0xffff800902067c50) [ 37.353970] 7b20: ffff000008e5d4c8 0001000000000000 0000000080f82000 0000000000000000 [ 37.361883] 7b40: ffff800902067b60 ffff000008e17000 ffff000008f44c68 00000001081081b4 [ 37.369802] 7b60: ffff800902067bf0 ffff000008108478 0000000000000000 ffff000008c235b0 [ 37.377721] 7b80: ffff800902067ce0 0000000000000000 0000000000000000 0000000000000015 [ 37.385643] 7ba0: 0000000000000123 000000000000008e ffff000008992000 ffff800902068000 [ 37.393557] 7bc0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 37.401477] 7be0: 0000000000000000 ffff000008c97dd8 ffff000008cc6fb0 ffff000008cc6fb8 [ 37.409396] 7c00: 6974726174736552 ffff800902067a50 0000000005f5e0ff ffff000008e70000 [ 37.417318] 7c20: ffff000008e706c0 ffff000008f42bfd ffff000088f42bef 0000000000000006 [ 37.425234] 7c40: 00000000deadbeef 0000ffffa7c27470 [ 37.430190] [< (null)>] (null) [ 37.434982] [<ffff000008085334>] machine_restart+0x6c/0x70 [ 37.440550] [<ffff0000080e2c2c>] kernel_restart+0x6c/0x78 [ 37.446030] [<ffff0000080e2ee8>] SyS_reboot+0x130/0x228 [ 37.451337] [<ffff0000080830f0>] el0_svc_naked+0x24/0x28 [ 37.456737] Code: bad PC value [ 37.459891] ---[ end trace 76e2fc17e050aecd ]--- Signed-off-by: Julien Grall <julien.grall@arm.com> -- Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org The x86 code has theoritically a similar issue, altought EFI does not seem to be the preferred method. I have only built test it on x86. This should also probably be fixed in stable tree. Changes in v2: - Implement xen_efi_reset_system using xen_reboot - Move xen_efi_reset_system in drivers/xen/efi.c Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02arm/xen: Consolidate calls to shutdown hypercall in a single helperJulien Grall1-6/+10
Signed-off-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02xen: Export xen_rebootJulien Grall2-1/+2
The helper xen_reboot will be called by the EFI code in a later patch. Note that the ARM version does not yet exist and will be added in a later patch too. Signed-off-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02xen/x86: Call xen_smp_intr_init_pv() on BSPBoris Ostrovsky1-1/+1
Recent code rework that split handling ov PV, HVM and PVH guests into separate files missed calling xen_smp_intr_init_pv() on CPU0. Add this call. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reported-by: Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02xen: Revert commits da72ff5bfcb0 and 72a9b186292dBoris Ostrovsky7-23/+54
Recent discussion (http://marc.info/?l=xen-devel&m=149192184523741) established that commit 72a9b186292d ("xen: Remove event channel notification through Xen PCI platform device") (and thus commit da72ff5bfcb0 ("partially revert "xen: Remove event channel notification through Xen PCI platform device"")) are unnecessary and, in fact, prevent HVM guests from booting on Xen releases prior to 4.0 Therefore we revert both of those commits. The summary of that discussion is below: Here is the brief summary of the current situation: Before the offending commit (72a9b186292): 1) INTx does not work because of the reset_watches path. 2) The reset_watches path is only taken if you have Xen > 4.0 3) The Linux Kernel by default will use vector inject if the hypervisor support. So even INTx does not work no body running the kernel with Xen > 4.0 would notice. Unless he explicitly disabled this feature either in the kernel or in Xen (and this can only be disabled by modifying the code, not user-supported way to do it). After the offending commit (+ partial revert): 1) INTx is no longer support for HVM (only for PV guests). 2) Any HVM guest The kernel will not boot on Xen < 4.0 which does not have vector injection support. Since the only other mode supported is INTx which. So based on this summary, I think before commit (72a9b186292) we were in much better position from a user point of view. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02xen/pvh: Do not fill kernel's e820 map in init_pvh_bootparams()Boris Ostrovsky1-14/+6
e820 map is updated with information from the zeropage (i.e. pvh_bootparams) by default_machine_specific_memory_setup(). With the way things are done now, we end up with a duplicated e820 map. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02xen/scsifront: use offset_in_page() macroGeliang Tang1-1/+1
Use offset_in_page() macro instead of open-coding. Signed-off-by: Geliang Tang <geliangtang@gmail.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02xen/arm,arm64: rename __generic_dma_ops to xen_get_dma_opsStefano Stabellini2-14/+14
Now that __generic_dma_ops is a xen specific function, rename it to xen_get_dma_ops. Change all the call sites appropriately. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: linux@armlinux.org.uk CC: catalin.marinas@arm.com CC: will.deacon@arm.com CC: boris.ostrovsky@oracle.com CC: jgross@suse.com CC: Julien Grall <julien.grall@arm.com>
2017-05-02xen/arm,arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."Stefano Stabellini7-23/+30
The following commit: commit 815dd18788fe0d41899f51b91d0560279cf16b0d Author: Bart Van Assche <bart.vanassche@sandisk.com> Date: Fri Jan 20 13:04:04 2017 -0800 treewide: Consolidate get_dma_ops() implementations rearranges get_dma_ops in a way that xen_dma_ops are not returned when running on Xen anymore, dev->dma_ops is returned instead (see arch/arm/include/asm/dma-mapping.h:get_arch_dma_ops and include/linux/dma-mapping.h:get_dma_ops). Fix the problem by storing dev->dma_ops in dev_archdata, and setting dev->dma_ops to xen_dma_ops. This way, xen_dma_ops is returned naturally by get_dma_ops. The Xen code can retrieve the original dev->dma_ops from dev_archdata when needed. It also allows us to remove __generic_dma_ops from common headers. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Julien Grall <julien.grall@arm.com> Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Cc: <stable@vger.kernel.org> [4.11+] CC: linux@armlinux.org.uk CC: catalin.marinas@arm.com CC: will.deacon@arm.com CC: boris.ostrovsky@oracle.com CC: jgross@suse.com CC: Julien Grall <julien.grall@arm.com>
2017-05-02xen/9pfs: select CONFIG_XEN_XENBUS_FRONTENDArnd Bergmann1-0/+1
All Xen frontends need to select this symbol to avoid a link error: net/built-in.o: In function `p9_trans_xen_init': :(.text+0x149e9c): undefined reference to `__xenbus_register_frontend' Fixes: d4b40a02f837 ("xen/9pfs: build 9pfs Xen transport driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2017-05-02x86/cpu: remove hypervisor specific set_cpu_featuresJuergen Gross3-14/+0
There is no user of x86_hyper->set_cpu_features() any more. Remove it. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02vmware: set cpu capabilities during platform initializationJuergen Gross1-19/+20
There is no need to set the same capabilities for each cpu individually. This can be done for all cpus in platform initialization. Cc: Alok Kataria <akataria@vmware.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Cc: virtualization@lists.linux-foundation.org Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Alok Kataria <akataria@vmware.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02x86/xen: use capabilities instead of fake cpuid values for xsaveJuergen Gross1-23/+30
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the xsave feature availability is indicated by special casing the related cpuid leaf. Instead of delivering fake cpuid values set or clear the cpu capability bits for xsave instead. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02x86/xen: use capabilities instead of fake cpuid values for x2apicJuergen Gross1-2/+1
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the x2apic feature is indicated as not being present by special casing the related cpuid leaf. Instead of delivering fake cpuid values clear the cpu capability bit for x2apic instead. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02x86/xen: use capabilities instead of fake cpuid values for mwaitJuergen Gross1-6/+5
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the mwait feature is indicated to be present or not by special casing the related cpuid leaf. Instead of delivering fake cpuid values use the cpu capability bit for mwait instead. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02x86/xen: use capabilities instead of fake cpuid values for acpiJuergen Gross1-8/+3
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the acpi feature is indicated as not being present by special casing the related cpuid leaf in case we are not the initial domain. Instead of delivering fake cpuid values clear the cpu capability bit for acpi instead. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02x86/xen: use capabilities instead of fake cpuid values for accJuergen Gross1-3/+1
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the acc feature (thermal monitoring) is indicated as not being present by special casing the related cpuid leaf. Instead of delivering fake cpuid values clear the cpu capability bit for acc instead. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02x86/xen: use capabilities instead of fake cpuid values for mtrrJuergen Gross1-2/+2
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the mtrr feature is indicated as not being present by special casing the related cpuid leaf. Instead of delivering fake cpuid values clear the cpu capability bit for mtrr instead. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02x86/xen: use capabilities instead of fake cpuid values for aperfJuergen Gross1-8/+1
When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the aperf/mperf feature is indicated as not being present by special casing the related cpuid leaf. Instead of delivering fake cpuid values clear the cpu capability bit for aperf/mperf instead. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02x86/xen: don't indicate DCA support in pv domainsJuergen Gross1-0/+1
Xen doesn't support DCA (direct cache access) for pv domains. Clear the corresponding capability indicator. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02xen: set cpu capabilities from xen_start_kernel()Juergen Gross1-7/+7
There is no need to set the same capabilities for each cpu individually. This can easily be done for all cpus when starting the kernel. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02xen/9pfs: initialize len to 0 to detect xenbus_read errorsStefano Stabellini1-1/+1
In order to use "len" to check for xenbus_read errors properly, we need to initialize len to 0 before passing it to xenbus_read. CC: dan.carpenter@oracle.com CC: jgross@suse.com CC: boris.ostrovsky@oracle.com CC: Eric Van Hensbergen <ericvh@gmail.com> CC: Ron Minnich <rminnich@sandia.gov> CC: Latchesar Ionkov <lucho@ionkov.net> CC: v9fs-developer@lists.sourceforge.net Signed-off-by: Stefano Stabellini <stefano@aporeto.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2017-05-02xen,kdump: handle pv domain in paddr_vmcoreinfo_note()Juergen Gross1-0/+13
For kdump to work correctly it needs the physical address of vmcoreinfo_note. When running as dom0 this means the virtual address has to be translated to the related machine address. paddr_vmcoreinfo_note() is meant to do the translation via __pa_symbol() only, but being attributed "weak" it can be replaced easily in Xen case. Signed-off-by: Juergen Gross <jgross@suse.com> Tested-by: Petr Tesarik <ptesarik@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>