aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-05-02audit: log module name on delete_moduleRichard Guy Briggs1-0/+2
When a sysadmin wishes to monitor module unloading with a syscall rule such as: -a always,exit -F arch=x86_64 -S delete_module -F key=mod-unload the SYSCALL record doesn't tell us what module was requested for unloading. Use the new KERN_MODULE auxiliary record to record it. The SYSCALL record result code will list the return code. See: https://github.com/linux-audit/audit-kernel/issues/37 https://github.com/linux-audit/audit-kernel/issues/7 https://github.com/linux-audit/audit-kernel/wiki/RFE-Module-Load-Record-Format Signed-off-by: Richard Guy Briggs <[email protected]> Acked-by: Jessica Yu <[email protected]> Signed-off-by: Paul Moore <[email protected]>
2017-05-02audit: remove unnecessary semicolon in audit_watch_handle_event()Nicholas Mc Guire1-1/+1
The excess ; after the closing parenthesis is just code-noise it has no and can be removed. Signed-off-by: Nicholas Mc Guire <[email protected]> [PM: tweaked subject line] Signed-off-by: Paul Moore <[email protected]>
2017-05-02audit: remove unnecessary semicolon in audit_mark_handle_event()Nicholas Mc Guire1-1/+1
The excess ; after the closing parenthesis is just code-noise it has no and can be removed. Signed-off-by: Nicholas Mc Guire <[email protected]> [PM: tweaked subject line] Signed-off-by: Paul Moore <[email protected]>
2017-05-02audit: remove unnecessary semicolon in audit_field_valid()Nicholas Mc Guire1-2/+2
The excess ; after the closing parenthesis is just code-noise it has no and can be removed. Signed-off-by: Nicholas Mc Guire <[email protected]> [PM: tweak subject line] Signed-off-by: Paul Moore <[email protected]>
2017-05-02xdp: fix parameter kdoc for extackJakub Kicinski1-1/+1
Fix kdoc parameter spelling from extact to extack. Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-05-02bpf, samples: fix build warning in cookie_uid_helper_exampleDaniel Borkmann1-3/+3
Fix the following warnings triggered by 51570a5ab2b7 ("A Sample of using socket cookie and uid for traffic monitoring"): In file included from /home/foo/net-next/samples/bpf/cookie_uid_helper_example.c:54:0: /home/foo/net-next/samples/bpf/cookie_uid_helper_example.c: In function 'prog_load': /home/foo/net-next/samples/bpf/cookie_uid_helper_example.c:119:27: warning: overflow in implicit constant conversion [-Woverflow] -32 + offsetof(struct stats, uid)), ^ /home/foo/net-next/samples/bpf/libbpf.h:135:12: note: in definition of macro 'BPF_STX_MEM' .off = OFF, \ ^ /home/foo/net-next/samples/bpf/cookie_uid_helper_example.c:121:27: warning: overflow in implicit constant conversion [-Woverflow] -32 + offsetof(struct stats, packets), 1), ^ /home/foo/net-next/samples/bpf/libbpf.h:155:12: note: in definition of macro 'BPF_ST_MEM' .off = OFF, \ ^ /home/foo/net-next/samples/bpf/cookie_uid_helper_example.c:129:27: warning: overflow in implicit constant conversion [-Woverflow] -32 + offsetof(struct stats, bytes)), ^ /home/foo/net-next/samples/bpf/libbpf.h:135:12: note: in definition of macro 'BPF_STX_MEM' .off = OFF, \ ^ HOSTLD /home/foo/net-next/samples/bpf/per_socket_stats_example Fixes: 51570a5ab2b7 ("A Sample of using socket cookie and uid for traffic monitoring") Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-05-02powerpc/eeh: Clean up and document event handling functionsRussell Currey1-12/+24
Remove unnecessary tags in eeh_handle_normal_event(), and add function comments for eeh_handle_normal_event() and eeh_handle_special_event(). The only functional difference is that in the case of a PE reaching the maximum number of failures, rather than one message telling you of this and suggesting you reseat the device, there are two separate messages. Suggested-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Russell Currey <[email protected]> Reviewed-by: Andrew Donnellan <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2017-05-02powerpc/eeh: Avoid use after free in eeh_handle_special_event()Russell Currey1-4/+15
eeh_handle_special_event() is called when an EEH event is detected but can't be narrowed down to a specific PE. This function looks through every PE to find one in an erroneous state, then calls the regular event handler eeh_handle_normal_event() once it knows which PE has an error. However, if eeh_handle_normal_event() found that the PE cannot possibly be recovered, it will free it, rendering the passed PE stale. This leads to a use after free in eeh_handle_special_event() as it attempts to clear the "recovering" state on the PE after eeh_handle_normal_event() returns. Thus, make sure the PE is valid when attempting to clear state in eeh_handle_special_event(). Fixes: 8a6b1bc70dbb ("powerpc/eeh: EEH core to handle special event") Cc: [email protected] # v3.11+ Reported-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Russell Currey <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2017-05-02cxl: Mask slice error interrupts after first occurrenceAlastair D'Silva2-2/+35
In some situations, a faulty AFU slice may create an interrupt storm of slice errors, rendering the machine unusable. Since these interrupts are informational only, present the interrupt once, then mask it off to prevent it from being retriggered until the AFU is reset. Signed-off-by: Alastair D'Silva <[email protected]> Reviewed-by: Andrew Donnellan <[email protected]> Reviewed-by: Vaibhav Jain <[email protected]> Acked-by: Frederic Barrat <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2017-05-02cxl: Route eeh events to all drivers in cxl_pci_error_detected()Vaibhav Jain1-6/+9
Fix a boundary condition where in some cases an eeh event that results in card reset isn't passed on to a driver attached to the virtual PCI device associated with a slice. This will happen in case when a slice attached device driver returns a value other than PCI_ERS_RESULT_NEED_RESET from the eeh error_detected() callback. This would result in an early return from cxl_pci_error_detected() and other drivers attached to other AFUs on the card wont be notified. The patch fixes this by making sure that all slice attached device-drivers are notified and the return values from error_detected() callback are aggregated in a scheme where request for 'disconnect' trumps all and 'none' trumps 'need_reset'. Fixes: 9e8df8a21963 ("cxl: EEH support") Cc: [email protected] # v4.3+ Signed-off-by: Vaibhav Jain <[email protected]> Reviewed-by: Andrew Donnellan <[email protected]> Acked-by: Frederic Barrat <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2017-05-02cxl: Force context lock during EEH flowVaibhav Jain1-2/+17
During an eeh event when the cxl card is fenced and card sysfs attr perst_reloads_same_image is set following warning message is seen in the kernel logs: Adapter context unlocked with 0 active contexts ------------[ cut here ]------------ WARNING: CPU: 12 PID: 627 at ../drivers/misc/cxl/main.c:325 cxl_adapter_context_unlock+0x60/0x80 [cxl] Even though this warning is harmless, it clutters the kernel log during an eeh event. This warning is triggered as the EEH callback cxl_pci_error_detected doesn't obtain a context-lock before forcibly detaching all active context and when context-lock is released during call to cxl_configure_adapter from cxl_pci_slot_reset, a warning in cxl_adapter_context_unlock is triggered. To fix this warning, we acquire the adapter context-lock via cxl_adapter_context_lock() in the eeh callback cxl_pci_error_detected() once all the virtual AFU PHBs are notified and their contexts detached. The context-lock is released in cxl_pci_slot_reset() after the adapter is successfully reconfigured and before the we call the slot_reset callback on slice attached device-drivers. Fixes: 70b565bbdb91 ("cxl: Prevent adapter reset if an active context exists") Cc: [email protected] # v4.9+ Reported-by: Andrew Donnellan <[email protected]> Signed-off-by: Vaibhav Jain <[email protected]> Acked-by: Frederic Barrat <[email protected]> Reviewed-by: Matthew R. Ochs <[email protected]> Tested-by: Uma Krishnan <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
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 <[email protected]> -- Cc: Boris Ostrovsky <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: [email protected] 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 <[email protected]>
2017-05-02arm/xen: Consolidate calls to shutdown hypercall in a single helperJulien Grall1-6/+10
Signed-off-by: Julien Grall <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reported-by: Sander Eikelenboom <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> CC: [email protected] CC: [email protected] CC: [email protected] CC: [email protected] CC: [email protected] CC: Julien Grall <[email protected]>
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 <[email protected]> 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 <[email protected]> Tested-by: Julien Grall <[email protected]> Suggested-by: Catalin Marinas <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Cc: <[email protected]> [4.11+] CC: [email protected] CC: [email protected] CC: [email protected] CC: [email protected] CC: [email protected] CC: Julien Grall <[email protected]>
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 <[email protected]> Reviewed-by: Stefano Stabellini <[email protected]>
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 <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: [email protected] Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Acked-by: Alok Kataria <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reviewed-by: Andrew Cooper <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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: [email protected] CC: [email protected] CC: [email protected] CC: Eric Van Hensbergen <[email protected]> CC: Ron Minnich <[email protected]> CC: Latchesar Ionkov <[email protected]> CC: [email protected] Signed-off-by: Stefano Stabellini <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
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 <[email protected]> Tested-by: Petr Tesarik <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02xen/displif: add ABI for para-virtual displayOleksandr Andrushchenko1-0/+854
This is the ABI for the two halves of a para-virtualized display driver. This protocol aims to provide a unified protocol which fits more sophisticated use-cases than a framebuffer device can handle. At the moment basic functionality is supported with the intention to extend: o multiple dynamically allocated/destroyed framebuffers o buffers of arbitrary sizes o better configuration options including multiple display support Note: existing fbif can be used together with displif running at the same time, e.g. on Linux one provides framebuffer and another DRM/KMS Future extensions to the existing protocol may include: o allow display/connector cloning o allow allocating objects other than display buffers o add planes/overlays support o support scaling o support rotation Note, that this protocol doesn't use ring macros for bi-directional exchange (PV calls/9pfs) bacause: o it statically defines the use of a single page for the ring buffer o it uses direct memory access to ring's contents w/o memory copying o re-uses the same idea that kbdif/fbif use which for this use-case seems to be appropriate ================================================== Rationale for introducing this protocol instead of using the existing fbif: ================================================== 1. In/out event sizes o fbif - 40 octets o displif - 40 octets This is only the initial version of the displif protocol which means that there could be requests which will not fit (WRT introducing some GPU related functionality later on). In that case we cannot alter fbif sizes as we need to be backward compatible an will be forced to handle those apart of fbif. 2. Shared page Displif doesn't use anything like struct xenfb_page, but DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct xendispl_resp) which is a better and more common way. Output events use a shared page which only has in_cons and in_prod and all the rest is used for incoming events. Here struct xenfb_page could probably be used as is despite the fact that it only has a half of a page for incoming events which is only 50 events. (consider something like 60Hz display) 3. Amount of changes. fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE events, so it looks like it is easier to get fb support into displif than vice versa. displif at the moment has 6 requests and 1 event, multiple connector support, etc. Signed-off-by: Oleksandr Grytsov <[email protected]> Signed-off-by: Oleksandr Andrushchenko <[email protected]> Acked-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02xen/sndif: add sound-device ABIOleksandr Andrushchenko1-0/+793
Add ABI for the two halves of a para-virtualized sound driver to communicate with each other. The ABI allows implementing audio playback and capture as well as volume control and possibility to mute/unmute audio sources. Note: depending on the use-case backend can expose more sound cards and PCM devices/streams than the underlying HW physically has by employing SW mixers, configuring virtual sound streams, channels etc. Thus, allowing fine tunned configurations per frontend. Signed-off-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Oleksandr Grytsov <[email protected]> Signed-off-by: Oleksandr Dmytryshyn <[email protected]> Signed-off-by: Iurii Konovalenko <[email protected]> Acked-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02xen/kbdif: add multi-touch supportOleksandr Andrushchenko1-0/+210
Multi-touch fields re-use the page that is used by the other features which means that you can interleave multi-touch, motion, and key events. Signed-off-by: Oleksandr Andrushchenko <[email protected]> Acked-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02xen/kbdif: update protocol descriptionOleksandr Andrushchenko1-27/+221
The patch clarifies the protocol that is used by the PV keyboard drivers. Signed-off-by: Oleksandr Andrushchenko <[email protected]> Acked-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02xen/9pfs: build 9pfs Xen transport driverStefano Stabellini2-0/+12
This patch adds a Kconfig option and Makefile support for building the 9pfs Xen driver. CC: [email protected] CC: [email protected] CC: [email protected] CC: Eric Van Hensbergen <[email protected]> CC: Ron Minnich <[email protected]> CC: Latchesar Ionkov <[email protected]> CC: [email protected] Signed-off-by: Stefano Stabellini <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02xen/9pfs: receive responsesStefano Stabellini1-0/+56
Upon receiving a notification from the backend, schedule the p9_xen_response work_struct. p9_xen_response checks if any responses are available, if so, it reads them one by one, calling p9_client_cb to send them up to the 9p layer (p9_client_cb completes the request). Handle the ring following the Xen 9pfs specification. CC: [email protected] CC: [email protected] CC: Eric Van Hensbergen <[email protected]> CC: Ron Minnich <[email protected]> CC: Latchesar Ionkov <[email protected]> CC: [email protected] Signed-off-by: Stefano Stabellini <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02xen/9pfs: send requests to the backendStefano Stabellini1-2/+85
Implement struct p9_trans_module create and close functions by looking at the available Xen 9pfs frontend-backend connections. We don't expect many frontend-backend connections, thus walking a list is OK. Send requests to the backend by copying each request to one of the available rings (each frontend-backend connection comes with multiple rings). Handle the ring and notifications following the 9pfs specification. If there are not enough free bytes on the ring for the request, wait on the wait_queue: the backend will send a notification after consuming more requests. CC: [email protected] CC: [email protected] CC: Eric Van Hensbergen <[email protected]> CC: Ron Minnich <[email protected]> CC: Latchesar Ionkov <[email protected]> CC: [email protected] Signed-off-by: Stefano Stabellini <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02xen/9pfs: connect to the backendStefano Stabellini1-0/+281
Implement functions to handle the xenbus handshake. Upon connection, allocate the rings according to the protocol specification. Initialize a work_struct and a wait_queue. The work_struct will be used to schedule work upon receiving an event channel notification from the backend. The wait_queue will be used to wait when the ring is full and we need to send a new request. CC: [email protected] CC: [email protected] CC: [email protected] CC: Eric Van Hensbergen <[email protected]> CC: Ron Minnich <[email protected]> CC: Latchesar Ionkov <[email protected]> CC: [email protected] Signed-off-by: Stefano Stabellini <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02xen/9pfs: introduce Xen 9pfs transport driverStefano Stabellini1-0/+125
Introduce the Xen 9pfs transport driver: add struct xenbus_driver to register as a xenbus driver and add struct p9_trans_module to register as v9fs driver. All functions are empty stubs for now. CC: [email protected] CC: [email protected] CC: Eric Van Hensbergen <[email protected]> CC: Ron Minnich <[email protected]> CC: Latchesar Ionkov <[email protected]> CC: [email protected] Signed-off-by: Stefano Stabellini <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02xen: introduce the header file for the Xen 9pfs transport protocolStefano Stabellini1-0/+36
It uses the new ring.h macros to declare rings and interfaces. CC: [email protected] CC: [email protected] CC: [email protected] CC: [email protected] Signed-off-by: Stefano Stabellini <[email protected]> Acked-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02xen: import new ring macros in ring.hStefano Stabellini1-0/+143
Sync the ring.h file with upstream Xen, to introduce the new ring macros. They will be used by the Xen transport for 9pfs. CC: [email protected] CC: [email protected] CC: [email protected] CC: [email protected] Signed-off-by: Stefano Stabellini <[email protected]> Acked-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02x86/xen: remove unused static function from smp_pv.cJuergen Gross1-10/+0
xen_call_function_interrupt() isn't used in smp_pv.c. Remove it. Signed-off-by: Juergen Gross <[email protected]>
2017-05-02x86/xen: rename some PV-only functions in smp_pv.cVitaly Kuznetsov1-14/+14
After code split between PV and HVM some functions in xen_smp_ops have xen_pv_ prefix and some only xen_ which makes them look like they're common for both PV and HVM while they're not. Rename all the rest to have xen_pv_ prefix. Signed-off-by: Vitaly Kuznetsov <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02x86/xen: enable PVHVM-only buildsVitaly Kuznetsov2-4/+9
Now everything is in place and we can move PV-only code under CONFIG_XEN_PV. CONFIG_XEN_PV_SMP is created to support the change. Signed-off-by: Vitaly Kuznetsov <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02xen: create xen_create/destroy_contiguous_region() stubs for PVHVM only buildsVitaly Kuznetsov1-0/+14
xen_create_contiguous_region()/xen_create_contiguous_region() are PV-only, they both contain xen_feature(XENFEAT_auto_translated_physmap) check and bail in the very beginning. Signed-off-by: Vitaly Kuznetsov <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2017-05-02xen/balloon: decorate PV-only parts with #ifdef CONFIG_XEN_PVVitaly Kuznetsov1-10/+20
Balloon driver uses several PV-only concepts (xen_start_info, xen_extra_mem,..) and it seems the simpliest solution to make HVM-only build happy is to decorate these parts with #ifdefs. Signed-off-by: Vitaly Kuznetsov <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.