- 26 Jul, 2016 1 commit
-
-
Juergen Gross authored
pv_time_ops might be overwritten with xen_time_ops after the steal_clock operation has been initialized already. To prevent calling a now uninitialized function pointer add the steal_clock static initialization to xen_time_ops. Signed-off-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
David Vrabel <david.vrabel@citrix.com>
-
- 25 Jul, 2016 10 commits
-
-
Vitaly Kuznetsov authored
Historically we didn't call VCPUOP_register_vcpu_info for CPU0 for PVHVM guests (while we had it for PV and ARM guests). This is usually fine as we can use vcpu info in the shared_info page but when we try booting on a vCPU with Xen's vCPU id > 31 (e.g. when we try to kdump after crashing on this CPU) we're not able to boot. Switch to always doing VCPUOP_register_vcpu_info for the boot CPU. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Use the newly introduced xen_vcpu_id mapping to get Xen's idea of vCPU id for CPU0. Signed-off-by:
-
Vitaly Kuznetsov authored
EVTCHNOP_init_control has vCPU id as a parameter and Xen's idea of vCPU id should be used. Use the newly introduced xen_vcpu_id mapping to convert it from Linux's id. Signed-off-by:
-
Vitaly Kuznetsov authored
EVTCHNOP_bind_ipi and EVTCHNOP_bind_virq pass vCPU id as a parameter and Xen's idea of vCPU id should be used. Use the newly introduced xen_vcpu_id mapping to convert it from Linux's id. Signed-off-by:
-
Vitaly Kuznetsov authored
shared_info page has space for 32 vcpu info slots for first 32 vCPUs but these are the first 32 vCPUs from Xen's perspective and we should map them accordingly with the newly introduced xen_vcpu_id mapping. Signed-off-by:
-
Vitaly Kuznetsov authored
HYPERVISOR_vcpu_op() passes Linux's idea of vCPU id as a parameter while Xen's idea is expected. In some cases these ideas diverge so we need to do remapping. Convert all callers of HYPERVISOR_vcpu_op() to use xen_vcpu_nr(). Leave xen_fill_possible_map() and xen_filter_cpu_maps() intact as they're only being called by PV guests before perpu areas are initialized. While the issue could be solved by switching to early_percpu for xen_vcpu_id I think it's not worth it: PV guests will probably never get to the point where their idea of vCPU id diverges from Xen's. Signed-off-by:
-
Vitaly Kuznetsov authored
It may happen that Xen's and Linux's ideas of vCPU id diverge. In particular, when we crash on a secondary vCPU we may want to do kdump and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting on the vCPU which crashed. This doesn't work very well for PVHVM guests as we have a number of hypercalls where we pass vCPU id as a parameter. These hypercalls either fail or do something unexpected. To solve the issue introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct mapping for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary CPUs it is a bit more trickier. Currently, we initialize IPI vectors before these CPUs boot so we can't use CPUID. Use ACPI ids from MADT instead. Signed-off-by:
-
Vitaly Kuznetsov authored
Currently we don't save ACPI ids (unlike LAPIC ids which go to x86_cpu_to_apicid) from MADT and we may need this information later. Particularly, ACPI ids is the only existent way for a PVHVM Xen guest to figure out Xen's idea of its vCPUs ids before these CPUs boot and in some cases these ids diverge from Linux's cpu ids. Signed-off-by:
-
Vitaly Kuznetsov authored
Update cpuid.h header from xen hypervisor tree to get XEN_HVM_CPUID_VCPU_ID_PRESENT definition. Signed-off-by:
-
David Vrabel authored
IOCTL_EVTCHN_RESTRICT limits the file descriptor to being able to bind to interdomain event channels from a specific domain. Event channels that are already bound continue to work for sending and receiving notifications. This is useful as part of deprivileging a user space PV backend or device model (QEMU). e.g., Once the device model as bound to the ioreq server event channels it can restrict the file handle so an exploited DM cannot use it to create or bind to arbitrary event channels. Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com>
-
- 22 Jul, 2016 4 commits
-
-
Jan Beulich authored
Commit 9d092603 ("xen-blkback: do not leak mode property") left one path unfixed; correct this. Acked-by:
Jens Axboe <axboe@kernel.dk> Acked-by:
Roger Pau Monné <roger.pau@citrix.com> Signed-off-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
Jan Beulich authored
The functions these get passed to have been taking pointers to const since at least 2.6.16. Acked-by:
-
Jan Beulich authored
... for single items being collected: It is more typesafe (as the compiler can check format string and to-be-written-to variable match) and requires one less parameter to be passed. Acked-by:
-
Jan Beulich authored
... for single items being collected: It is more typesafe (as the compiler can check format string and to-be-written-to variable match) and requires one less parameter to be passed. Signed-off-by:
-
- 06 Jul, 2016 25 commits
-
-
Juergen Gross authored
Up to now reading the stolen time of a remote cpu was not possible in a performant way under Xen. This made support of runqueue steal time via paravirt_steal_rq_enabled impossible. With the addition of an appropriate hypervisor interface this is now possible, so add the support. Signed-off-by:
Stefano Stabellini <sstabellini@kernel.org> Signed-off-by:
-
Juergen Gross authored
Add support for the Xen HYPERVISOR_vm_assist hypercall. Signed-off-by:
Julien Grall <julien.grall@arm.com> Reviewed-by:
-
Juergen Gross authored
Update some Xen headers to be able to use new functionality. Signed-off-by:
-
Jan Beulich authored
req_start is simply an alias of the "offset" function parameter, and req_end is being used just once in each function. (And both variables were loop invariant anyway, so should at least have got initialized outside the loop.) Signed-off-by:
-
Jan Beulich authored
There's no point calling xen_pcibk_config_read() here - all it'll do is return whatever conf_space_read() returns for the field which was found here (and which would be found there again). Also there's no point clearing tmp_val before the call. Signed-off-by:
-
Jan Beulich authored
Signed-off-by:
-
Jan Beulich authored
Other than for raw BAR values, flags are properly separated in the internal representation. Signed-off-by:
-
Jan Beulich authored
Signed-off-by:
-
Jan Beulich authored
It is now identical to bar_init(). Signed-off-by:
-
Jan Beulich authored
Signed-off-by:
-
Amitoj Kaur Chawla authored
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) /(d)) but is perhaps more readable. The Coccinelle script used to make this change is as follows: @haskernel@ @@ #include <linux/kernel.h> @depends on haskernel@ expression n,d; @@ ( - (n + d - 1) / d + DIV_ROUND_UP(n,d) | - (n + (d - 1)) / d + DIV_ROUND_UP(n,d) ) Signed-off-by:
Amitoj Kaur Chawla <amitoj1606@gmail.com> Signed-off-by:
-
Bhaktipriya Shridhar authored
System workqueues have been able to handle high level of concurrency for a long time now and there's no reason to use dedicated workqueues just to gain concurrency. Replace dedicated xenbus_frontend_wq with the use of system_wq. Unlike a dedicated per-cpu workqueue created with create_workqueue(), system_wq allows multiple work items to overlap executions even on the same CPU; however, a per-cpu workqueue doesn't have any CPU locality or global ordering guarantees unless the target CPU is explicitly specified and the increase of local concurrency shouldn't make any difference. In this case, there is only a single work item, increase of concurrency level by switching to system_wq should not make any difference. Signed-off-by:
Bhaktipriya Shridhar <bhaktipriya96@gmail.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Bhaktipriya Shridhar authored
System workqueues have been able to handle high level of concurrency for a long time now and there's no reason to use dedicated workqueues just to gain concurrency. Replace dedicated xen_pcibk_wq with the use of system_wq. Unlike a dedicated per-cpu workqueue created with create_workqueue(), system_wq allows multiple work items to overlap executions even on the same CPU; however, a per-cpu workqueue doesn't have any CPU locality or global ordering guarantees unless the target CPU is explicitly specified and thus the increase of local concurrency shouldn't make any difference. Since the work items could be pending, flush_work() has been used in xen_pcibk_disconnect(). xen_pcibk_xenbus_remove() calls free_pdev() which in turn calls xen_pcibk_disconnect() for every pdev to ensure that there is no pending task while disconnecting the driver. Signed-off-by:
-
Boris Ostrovsky authored
This will match how PMU errors are reported at check_hw_exists()'s msr_fail label, which is reached when VPMU initialzation fails. Signed-off-by:
-
Juergen Gross authored
The pv_time_ops structure contains a function pointer for the "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 uses its own mechanism to account for the "stolen" time a thread wasn't able to run due to hypervisor scheduling. Add support in Xen arch independent time handling for this feature by moving it out of the arm arch into drivers/xen and remove the x86 Xen hack. Signed-off-by:
-
Muhammad Falak R Wani authored
Replace explicit computation of vma page count by a call to vma_pages(). Signed-off-by:
Muhammad Falak R Wani <falakreyaz@gmail.com> Reviewed-by:
-
Shannon Zhao authored
The EFI DT parameters for bare metal are located under /chosen node, while for Xen Dom0 they are located under /hyperviosr/uefi node. These parameters under /chosen and /hyperviosr/uefi are not expected to appear at the same time. Parse these EFI parameters and initialize EFI like the way for bare metal except the runtime services because the runtime services for Xen Dom0 are available through hypercalls and they are always enabled. So it sets the EFI_RUNTIME_SERVICES flag if it finds /hyperviosr/uefi node and bails out in arm_enable_runtime_services() when EFI_RUNTIME_SERVICES flag is set already. Signed-off-by:
Shannon Zhao <shannon.zhao@linaro.org> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk>
-
Shannon Zhao authored
Sometimes it needs to check if there is a subnode of given node in FDT by given name. Introduce this helper to get the subnode if it exists. CC: Rob Herring <robh@kernel.org> Signed-off-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by:
Rob Herring <robh@kernel.org> Tested-by:
-
Shannon Zhao authored
When running on Xen hypervisor, runtime services are supported through hypercall. Add a Xen specific function to initialize runtime services. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
Shannon Zhao authored
Move x86 specific codes to architecture directory and export those EFI runtime service functions. This will be useful for initializing runtime service on ARM later. Signed-off-by:
-
Shannon Zhao authored
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could scan this to get the UEFI information. CC: Rob Herring <robh@kernel.org> Signed-off-by:
-
Shannon Zhao authored
Move xen_early_init() before efi_init(), then when calling efi_init() could initialize Xen specific UEFI. Check if it runs on Xen hypervisor through the flat dts. Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by:
-
Shannon Zhao authored
The kernel will get the event-channel IRQ through HVM_PARAM_CALLBACK_IRQ. Signed-off-by:
-
Shannon Zhao authored
This new delivery type which is for ARM shares the same value with HVM_PARAM_CALLBACK_TYPE_VECTOR which is for x86. val[15:8] is flag: val[7:0] is a PPI. To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and bit 9 stands the interrupt polarity is active low(1) or high(0). Signed-off-by:
-
Shannon Zhao authored
Sync the changes of HVM_PARAM_CALLBACK_VIA ABI introduced by Xen commit <ca5c54b6ff05> (public/hvm: export the HVM_PARAM_CALLBACK_VIA ABI in the API). Signed-off-by:
-
