- 16 Dec, 2015 9 commits
-
-
Andrey Smetanin authored
The SynIC message protocol mandates that the message slot is claimed by atomically setting message type to something other than HVMSG_NONE. If another message is to be delivered while the slot is still busy, message pending flag is asserted to indicate to the guest that the hypervisor wants to be notified when the slot is released. To make sure the protocol works regardless of where the message sources are (kernel or userspace), clear the pending flag on SINT ACK notification, and let the message sources compete for the slot again. Signed-off-by:
Andrey Smetanin <asmetanin@virtuozzo.com> Reviewed-by:
Roman Kagan <rkagan@virtuozzo.com> CC: Gleb Natapov <gleb@kernel.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: "K. Y. Srinivasan" <kys@microsoft.com> CC: Haiyang Zhang <haiyangz@microsoft.com> CC: Vitaly Kuznetsov <vkuznets@redhat.com> CC: Roman Kagan <rkagan@virtuozzo.com> CC: Denis V. Lunev <den@openvz.org> CC: qemu-devel@nongnu.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Andrey Smetanin authored
This helper will be used also in Hyper-V SynIC timers implementation. Signed-off-by:
-
Andrey Smetanin authored
Signed-off-by:
-
Andrey Smetanin authored
This rearrangement places functions declarations together according to their functionality, so future additions will be simplier. Signed-off-by:
-
Andrey Smetanin authored
This struct is required for Hyper-V SynIC timers implementation inside KVM and for upcoming Hyper-V VMBus support by userspace(QEMU). So place it into Hyper-V UAPI header. Signed-off-by:
-
Andrey Smetanin authored
This struct is required for Hyper-V SynIC timers implementation inside KVM and for upcoming Hyper-V VMBus support by userspace(QEMU). So place it into Hyper-V UAPI header. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Reviewed-by:
-
Andrey Smetanin authored
This constant is required for Hyper-V SynIC timers MSR's support by userspace(QEMU). Signed-off-by:
-
Andrey Smetanin authored
enum hv_message_type inside struct hv_message, hv_post_message is not size portable. Replace enum by u32. Signed-off-by:
-
Paolo Bonzini authored
Merge tag 'kvm-s390-next-4.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD KVM: s390 features and fixes for 4.5 (kvm/next) Some small cleanups - use assignment instead of memcpy - use %pK for kernel pointers Changes regarding guest memory size - Fix an off-by-one error in our guest memory interface (we might use unnecessarily big page tables, e.g. 3 levels for a 2GB guest instead of 2 levels) - We now ask the machine about the max. supported guest address and limit accordingly.
-
- 15 Dec, 2015 4 commits
-
-
Guenther Hutzl authored
Verify that the guest maximum storage address is below the MHA (maximum host address) value allowed on the host. Acked-by:
Michael Holzheu <holzheu@linux.vnet.ibm.com> Reviewed-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
Guenther Hutzl <hutzl@linux.vnet.ibm.com> Signed-off-by:
Dominik Dingel <dingel@linux.vnet.ibm.com> [adopt to match recent limit,size changes] Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
Dominik Dingel authored
While the userspace interface requests the maximum size the gmap code expects to get a maximum address. This error resulted in bigger page tables than necessary for some guest sizes, e.g. a 2GB guest used 3 levels instead of 2. At the same time we introduce KVM_S390_NO_MEM_LIMIT, which allows in a bright future that a guest spans the complete 64 bit address space. We also switch to TASK_MAX_SIZE for the initial memory size, this is a cosmetic change as the previous size also resulted in a 4 level pagetable creation. Reported-by:
-
Christian Borntraeger authored
The s390dbf and trace events provide a debugfs interface. If kptr_restrict is active, we should not expose kernel pointers. We can fence the debugfs output by using %pK instead of %p. Cc: Kees Cook <keescook@chromium.org> Reviewed-by:
-
Christian Borntraeger authored
Replace two memcpy with proper assignment. Suggested-by:
-
- 02 Dec, 2015 1 commit
-
-
Paolo Bonzini authored
Merge tag 'kvm-s390-next-4.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD KVM: s390 features, kvm_get_vcpu_by_id and stat Several features for s390 1. ESCA support (up to 248 vCPUs) 2. KVM detection: we can now detect if we support KVM (e.g. does KVM under KVM work?) kvm_stat: 1. cleanup the exit path kvm_get_vcpu_by_id: 1. Use kvm_get_vcpu_by_id where appropriate 2. Apply a heuristic to optimize for ID VCPU == No. VCPU
-
- 30 Nov, 2015 23 commits
-
-
Christian Borntraeger authored
rc already contains -ENOMEM, no need to assign it twice. Signed-off-by:
-
Heiko Carstens authored
This evaluates always to 'true'. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Reviewed-by:
-
David Hildenbrand authored
If we don't have support for virtualization (SIE), e.g. when running under a hypervisor not supporting execution of the SIE instruction, we should immediately abort loading the kvm module, as the SIE instruction cannot be enabled dynamically. Currently, the SIE instructions fails with an exception on a non-SIE host, resulting in the guest making no progress, instead of failing hard. Reviewed-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
David Hildenbrand authored
This patch exposes the SIE capability (aka virtualization support) via /proc/cpuinfo -> "features" as "sie". As we don't want to expose this hwcap via elf, let's add a second, "internal"/non-elf capability list. The content is simply concatenated to the existing features when printing /proc/cpuinfo. We also add the defines to elf.h to keep the hwcap stuff at a common place. Acked-by:
-
David Hildenbrand authored
This patch adds a way to check if the SIE with zArchitecture support is available. Acked-by:
-
David Hildenbrand authored
sca_add_vpcu is not called for ucontrol guests. We must also not apply the sca checking for sca_can_add_vcpu as ucontrol guests do not have to follow the sca limits. As common code already checks that id < KVM_MAX_VCPUS all other data structures are safe as well. Signed-off-by:
-
David Hildenbrand authored
Now that we already have kvm and the VCPU id set for the VCPU, we can convert sda_add_vcpu to look much more like sda_del_vcpu. Signed-off-by:
-
David Hildenbrand authored
Let's always set and clear the sda when enabling/disabling a VCPU. Dealing with sda being set to something else makes no sense anymore as we enable a VCPU in the SCA now after it has been registered at the VM. Signed-off-by:
-
David Hildenbrand authored
If something goes wrong in kvm_arch_vcpu_create, the VCPU has already been added to the sca but will never be removed. Trying to create VCPUs with duplicate ids (e.g. after a failed attempt) is problematic. Also, when creating multiple VCPUs in parallel, we could theoretically forget to set the correct SCA when the switch to ESCA happens just before the VCPU is registered. Let's add the VCPU to the SCA in kvm_arch_vcpu_postcreate, where we can be sure that no duplicate VCPU with the same id is around and the VCPU has already been registered at the VM. We also have to make sure to update ECB at that point. Signed-off-by:
-
David Hildenbrand authored
Having no sca can never happen, even when something goes wrong when switching to ESCA. Otherwise we would have a serious bug. Let's remove this superfluous check. Acked-by:
-
David Hildenbrand authored
If CPUSTAT_ECALL_PEND isn't set, we can't have an external call pending, so we can directly avoid taking the lock. Acked-by:
-
Eugene (jno) Dvurechenski authored
This patch allows s390 to have more than 64 VCPUs for a guest (up to 248 for memory usage considerations), if supported by the underlaying hardware (sclp.has_esca). Signed-off-by:
Eugene (jno) Dvurechenski <jno@linux.vnet.ibm.com> Signed-off-by:
-
Eugene (jno) Dvurechenski authored
This patch adds code that performs transparent switch to Extended SCA on addition of 65th VCPU in a VM. Disposal of ESCA is added too. The entier ESCA functionality, however, is still not enabled. The enablement will be provided in a separate patch. This patch also uses read/write lock protection of SCA and its subfields for possible disposal at the BSCA-to-ESCA transition. While only Basic SCA needs such a protection (for the swap), any SCA access is now guarded. Signed-off-by:
-
Eugene (jno) Dvurechenski authored
This patch updates the routines (sca_*) to provide transparent access to and manipulation on the data for both Basic and Extended SCA in use. The kvm.arch.sca is generalized to (void *) to handle BSCA/ESCA cases. Also the kvm.arch.use_esca flag is provided. The actual functionality is kept the same. Signed-off-by:
-
Eugene (jno) Dvurechenski authored
This patch adds new structures and updates some existing ones to provide the base for Extended SCA functionality. The old sca_* structures were renamed to bsca_* to keep things uniform. The access to fields of SIGP controls were turned into bitfields instead of hardcoded bitmasks. Signed-off-by:
-
Eugene (jno) Dvurechenski authored
This patch provides SCA-aware helpers to create/delete a VCPU. This is to prepare for upcoming introduction of Extended SCA support. Signed-off-by:
-
Eugene (jno) Dvurechenski authored
This patch generalizes access to the SIGP controls, which is a part of SCA. This is to prepare for upcoming introduction of Extended SCA support. Signed-off-by:
-
Eugene (jno) Dvurechenski authored
This patch generalizes access to the IPTE controls, which is a part of SCA. This is to prepare for upcoming introduction of Extended SCA support. Signed-off-by:
-
Eugene (jno) Dvurechenski authored
Introduce sclp.has_hvs and sclp.has_esca to provide a way for kvm to check whether the extended-SCA and the home-virtual-SCA facilities are available. Signed-off-by:
-
David Hildenbrand authored
Let's rewrite this function to better reflect how we actually handle exit_code. By dropping out early we can save a few cycles. This especially speeds up sie exits caused by host irqs. Also, let's move the special -EOPNOTSUPP for intercepts to the place where it belongs and convert it to -EREMOTE. Reviewed-by:
-
Janosch Frank authored
KVM creates debugfs files to export VM statistics to userland. To be able to remove them on kvm exit it tracks the files' dentries. Since their parent directory is also tracked and since each parent direntry knows its children we can easily remove them by using debugfs_remove_recursive(kvm_debugfs_dir). Therefore we don't need the extra tracking in the kvm_stats_debugfs_item anymore. Signed-off-by:
Janosch Frank <frankja@linux.vnet.ibm.com> Reviewed-By:
Sascha Silbe <silbe@linux.vnet.ibm.com> Acked-by:
-
David Hildenbrand authored
Usually, VCPU ids match the array index. So let's try a fast lookup first before falling back to the slow iteration. Suggested-by:
-
David Hildenbrand authored
Let's reuse the new common function for VPCU lookup by id. Reviewed-by:
-
- 26 Nov, 2015 3 commits
-
-
Takuya Yoshikawa authored
Signed-off-by:
Takuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp> Signed-off-by:
-
Takuya Yoshikawa authored
As kvm_mmu_get_page() was changed so that every parent pointer would not get into the sp->parent_ptes chain before the entry pointed to by it was set properly, we can use the for_each_rmap_spte macro instead of pte_list_walk(). Signed-off-by:
-
Takuya Yoshikawa authored
Every time kvm_mmu_get_page() is called with a non-NULL parent_pte argument, link_shadow_page() follows that to set the parent entry so that the new mapping will point to the returned page table. Moving parent_pte handling there allows to clean up the code because parent_pte is passed to kvm_mmu_get_page() just for mark_unsync() and mmu_page_add_parent_pte(). In addition, the patch avoids calling mark_unsync() for other parents in the sp->parent_ptes chain than the newly added parent_pte, because they have been there since before the current page fault handling started. Signed-off-by:
-
