Re: linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
On Mon, 13 Jul 2020 14:40:36 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
>
> arch/arm64/kvm/mmu.c
>
> between commit:
>
> c1a33aebe91d ("KVM: arm64: Use common KVM implementation of MMU memory
> caches")
>
> from the kvm tree and commit:
>
> a0e50aa3f4a8 ("KVM: arm64: Factor out stage 2 page table data from struct
> kvm")
>
> from the kvm-arm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc arch/arm64/kvm/mmu.c
> index 838aad520f1c,cd14c831d56f..
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@@ -124,11 -127,44 +127,12 @@@ static void stage2_dissolve_pud(struct
> put_page(virt_to_page(pudp));
> }
>
> - static void clear_stage2_pgd_entry(struct kvm *kvm, pgd_t *pgd, phys_addr_t
> addr)
> -static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
> - int min, int max)
> -{
> -void *page;
> -
> -BUG_ON(max > KVM_NR_MEM_OBJS);
> -if (cache->nobjs >= min)
> -return 0;
> -while (cache->nobjs < max) {
> -page = (void *)__get_free_page(GFP_PGTABLE_USER);
> -if (!page)
> -return -ENOMEM;
> -cache->objects[cache->nobjs++] = page;
> -}
> -return 0;
> -}
> -
> -static void mmu_free_memory_cache(struct kvm_mmu_memory_cache *mc)
> -{
> -while (mc->nobjs)
> -free_page((unsigned long)mc->objects[--mc->nobjs]);
> -}
> -
> -static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc)
> -{
> -void *p;
> -
> -BUG_ON(!mc || !mc->nobjs);
> -p = mc->objects[--mc->nobjs];
> -return p;
> -}
> -
> + static void clear_stage2_pgd_entry(struct kvm_s2_mmu *mmu, pgd_t *pgd,
> phys_addr_t addr)
> {
> + struct kvm *kvm = mmu->kvm;
> p4d_t *p4d_table __maybe_unused = stage2_p4d_offset(kvm, pgd, 0UL);
> stage2_pgd_clear(kvm, pgd);
> - kvm_tlb_flush_vmid_ipa(kvm, addr);
> + kvm_tlb_flush_vmid_ipa(mmu, addr, S2_NO_LEVEL_HINT);
> stage2_p4d_free(kvm, p4d_table);
> put_page(virt_to_page(pgd));
> }
This is now a conflict between the kvm-arm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpOv5NIHwSwj.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
On Mon, 13 Jul 2020 14:39:35 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the kvm-arm tree got conflicts in:
>
> arch/arm64/include/asm/kvm_coproc.h
> arch/arm64/kvm/handle_exit.c
>
> between commit:
>
> 74cc7e0c35c1 ("KVM: arm64: clean up redundant 'kvm_run' parameters")
>
> from the kvm tree and commits:
>
> 6b33e0d64f85 ("KVM: arm64: Drop the target_table[] indirection")
> 750ed5669380 ("KVM: arm64: Remove the target table")
> 3a949f4c9354 ("KVM: arm64: Rename HSR to ESR")
>
> from the kvm-arm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc arch/arm64/include/asm/kvm_coproc.h
> index 454373704b8a,147f3a77e6a5..
> --- a/arch/arm64/include/asm/kvm_coproc.h
> +++ b/arch/arm64/include/asm/kvm_coproc.h
> @@@ -19,20 -19,12 +19,12 @@@ struct kvm_sys_reg_table
> size_t num;
> };
>
> - struct kvm_sys_reg_target_table {
> - struct kvm_sys_reg_table table64;
> - struct kvm_sys_reg_table table32;
> - };
> -
> - void kvm_register_target_sys_reg_table(unsigned int target,
> -struct kvm_sys_reg_target_table *table);
> -
> -int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run);
> -int kvm_handle_cp14_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
> -int kvm_handle_cp14_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
> -int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
> -int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
> -int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run);
> +int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu);
> +int kvm_handle_cp14_32(struct kvm_vcpu *vcpu);
> +int kvm_handle_cp14_64(struct kvm_vcpu *vcpu);
> +int kvm_handle_cp15_32(struct kvm_vcpu *vcpu);
> +int kvm_handle_cp15_64(struct kvm_vcpu *vcpu);
> +int kvm_handle_sys_reg(struct kvm_vcpu *vcpu);
>
> #define kvm_coproc_table_init kvm_sys_reg_table_init
> void kvm_sys_reg_table_init(void);
> diff --cc arch/arm64/kvm/handle_exit.c
> index 1df3beafd73f,98ab33139982..
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@@ -87,9 -87,9 +87,9 @@@ static int handle_no_fpsimd(struct kvm_
>* world-switches and schedule other host processes until there is an
>* incoming IRQ or FIQ to the VM.
>*/
> -static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +static int kvm_handle_wfx(struct kvm_vcpu *vcpu)
> {
> - if (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
> + if (kvm_vcpu_get_esr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
> trace_kvm_wfx_arm64(*vcpu_pc(vcpu), true);
> vcpu->stat.wfe_exit_stat++;
> kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
> @@@ -114,12 -115,11 +114,12 @@@
>* guest and host are using the same debug facilities it will be up to
>* userspace to re-inject the correct exception for guest delivery.
>*
> - * @return: 0 (while setting run->exit_reason), -1 for error
> + * @return: 0 (while setting vcpu->run->exit_reason), -1 for error
>*/
> -static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run
> *run)
> +static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu)
> {
> +struct kvm_run *run = vcpu->run;
> - u32 hsr = kvm_vcpu_get_hsr(vcpu);
> + u32 esr = kvm_vcpu_get_esr(vcpu);
> int ret = 0;
>
> run->exit_reason = KVM_EXIT_DEBUG;
> @@@ -144,12 -144,12 +144,12 @@@
> return ret;
> }
>
> -static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu)
> {
> - u32 hsr = kvm_vcpu_get_hsr(vcpu);
> + u32 esr = kvm_vcpu_get_esr(vcpu);
>
> - kvm_pr_unimpl("Unknown exception class: hsr: %#08x -- %s\n",
> - hsr, esr_get_class_string(hsr));
> + kvm_pr_unimpl("Unknown exception class: esr: %#08x -- %s\n",
> + esr, esr_get_class_string(esr));
>
> kvm_inject_undefined(vcpu);
> return 1;
> @@@ -237,12 -237,11 +237,12 @@@ static int handle_trap_exceptions(struc
>* Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason) on
>* proper exit to userspace.
>*/
> -int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
> - int exception_index)
> +int handle_exit(struct kvm_vcpu *vcpu, int exception_index)
> {
> +struct kvm_run *run = vcpu->run;
> +
> if (ARM_SERROR_PENDING(exception_index)) {
> - u8 hsr_ec = ESR_ELx_EC(kvm_vcpu_get_hsr(vcpu));
> + u8 esr_ec = ESR_ELx_EC(kvm_vcpu_get_esr(vc
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
arch/arm64/kvm/mmu.c
between commit:
c1a33aebe91d ("KVM: arm64: Use common KVM implementation of MMU memory
caches")
from the kvm tree and commit:
a0e50aa3f4a8 ("KVM: arm64: Factor out stage 2 page table data from struct
kvm")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/kvm/mmu.c
index 838aad520f1c,cd14c831d56f..
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@@ -124,11 -127,44 +127,12 @@@ static void stage2_dissolve_pud(struct
put_page(virt_to_page(pudp));
}
- static void clear_stage2_pgd_entry(struct kvm *kvm, pgd_t *pgd, phys_addr_t
addr)
-static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
-int min, int max)
-{
- void *page;
-
- BUG_ON(max > KVM_NR_MEM_OBJS);
- if (cache->nobjs >= min)
- return 0;
- while (cache->nobjs < max) {
- page = (void *)__get_free_page(GFP_PGTABLE_USER);
- if (!page)
- return -ENOMEM;
- cache->objects[cache->nobjs++] = page;
- }
- return 0;
-}
-
-static void mmu_free_memory_cache(struct kvm_mmu_memory_cache *mc)
-{
- while (mc->nobjs)
- free_page((unsigned long)mc->objects[--mc->nobjs]);
-}
-
-static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc)
-{
- void *p;
-
- BUG_ON(!mc || !mc->nobjs);
- p = mc->objects[--mc->nobjs];
- return p;
-}
-
+ static void clear_stage2_pgd_entry(struct kvm_s2_mmu *mmu, pgd_t *pgd,
phys_addr_t addr)
{
+ struct kvm *kvm = mmu->kvm;
p4d_t *p4d_table __maybe_unused = stage2_p4d_offset(kvm, pgd, 0UL);
stage2_pgd_clear(kvm, pgd);
- kvm_tlb_flush_vmid_ipa(kvm, addr);
+ kvm_tlb_flush_vmid_ipa(mmu, addr, S2_NO_LEVEL_HINT);
stage2_p4d_free(kvm, p4d_table);
put_page(virt_to_page(pgd));
}
pgpAbFCqgwYcD.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got conflicts in:
arch/arm64/include/asm/kvm_coproc.h
arch/arm64/kvm/handle_exit.c
between commit:
74cc7e0c35c1 ("KVM: arm64: clean up redundant 'kvm_run' parameters")
from the kvm tree and commits:
6b33e0d64f85 ("KVM: arm64: Drop the target_table[] indirection")
750ed5669380 ("KVM: arm64: Remove the target table")
3a949f4c9354 ("KVM: arm64: Rename HSR to ESR")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/include/asm/kvm_coproc.h
index 454373704b8a,147f3a77e6a5..
--- a/arch/arm64/include/asm/kvm_coproc.h
+++ b/arch/arm64/include/asm/kvm_coproc.h
@@@ -19,20 -19,12 +19,12 @@@ struct kvm_sys_reg_table
size_t num;
};
- struct kvm_sys_reg_target_table {
- struct kvm_sys_reg_table table64;
- struct kvm_sys_reg_table table32;
- };
-
- void kvm_register_target_sys_reg_table(unsigned int target,
- struct kvm_sys_reg_target_table *table);
-
-int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run);
-int kvm_handle_cp14_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
-int kvm_handle_cp14_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
-int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
-int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
-int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu);
+int kvm_handle_cp14_32(struct kvm_vcpu *vcpu);
+int kvm_handle_cp14_64(struct kvm_vcpu *vcpu);
+int kvm_handle_cp15_32(struct kvm_vcpu *vcpu);
+int kvm_handle_cp15_64(struct kvm_vcpu *vcpu);
+int kvm_handle_sys_reg(struct kvm_vcpu *vcpu);
#define kvm_coproc_table_init kvm_sys_reg_table_init
void kvm_sys_reg_table_init(void);
diff --cc arch/arm64/kvm/handle_exit.c
index 1df3beafd73f,98ab33139982..
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@@ -87,9 -87,9 +87,9 @@@ static int handle_no_fpsimd(struct kvm_
* world-switches and schedule other host processes until there is an
* incoming IRQ or FIQ to the VM.
*/
-static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
+static int kvm_handle_wfx(struct kvm_vcpu *vcpu)
{
- if (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
+ if (kvm_vcpu_get_esr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
trace_kvm_wfx_arm64(*vcpu_pc(vcpu), true);
vcpu->stat.wfe_exit_stat++;
kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
@@@ -114,12 -115,11 +114,12 @@@
* guest and host are using the same debug facilities it will be up to
* userspace to re-inject the correct exception for guest delivery.
*
- * @return: 0 (while setting run->exit_reason), -1 for error
+ * @return: 0 (while setting vcpu->run->exit_reason), -1 for error
*/
-static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
+static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu)
{
+ struct kvm_run *run = vcpu->run;
- u32 hsr = kvm_vcpu_get_hsr(vcpu);
+ u32 esr = kvm_vcpu_get_esr(vcpu);
int ret = 0;
run->exit_reason = KVM_EXIT_DEBUG;
@@@ -144,12 -144,12 +144,12 @@@
return ret;
}
-static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
+static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu)
{
- u32 hsr = kvm_vcpu_get_hsr(vcpu);
+ u32 esr = kvm_vcpu_get_esr(vcpu);
- kvm_pr_unimpl("Unknown exception class: hsr: %#08x -- %s\n",
- hsr, esr_get_class_string(hsr));
+ kvm_pr_unimpl("Unknown exception class: esr: %#08x -- %s\n",
+ esr, esr_get_class_string(esr));
kvm_inject_undefined(vcpu);
return 1;
@@@ -237,12 -237,11 +237,12 @@@ static int handle_trap_exceptions(struc
* Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason) on
* proper exit to userspace.
*/
-int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
- int exception_index)
+int handle_exit(struct kvm_vcpu *vcpu, int exception_index)
{
+ struct kvm_run *run = vcpu->run;
+
if (ARM_SERROR_PENDING(exception_index)) {
- u8 hsr_ec = ESR_ELx_EC(kvm_vcpu_get_hsr(vcpu));
+ u8 esr_ec = ESR_ELx_EC(kvm_vcpu_get_esr(vcpu));
/*
* HVC/SMC already have an adjusted PC, which we need
pgpb4EpwgtROB.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
include/uapi/linux/kvm.h
between commits:
214ff83d4473 ("KVM: x86: hyperv: implement PV IPI send hypercalls")
0804c849f1df ("kvm/x86 : add coalesced pio support")
57b119da3594 ("KVM: nVMX: add KVM_CAP_HYPERV_ENLIGHTENED_VMCS capability")
c4f55198c7c2 ("kvm: x86: Introduce KVM_CAP_EXCEPTION_PAYLOAD")
from the kvm tree and commit:
233a7cb23531 ("kvm: arm64: Allow tuning the physical address size for VM")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/uapi/linux/kvm.h
index cb6d44e1fe02,95aa73ca65dc..
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -960,11 -962,7 +969,12 @@@ struct kvm_ppc_resize_hpt
#define KVM_CAP_NESTED_STATE 157
#define KVM_CAP_ARM_INJECT_SERROR_ESR 158
#define KVM_CAP_MSR_PLATFORM_INFO 159
-#define KVM_CAP_ARM_VM_IPA_SIZE 160 /* returns maximum IPA bits for a VM */
+#define KVM_CAP_PPC_NESTED_HV 160
+#define KVM_CAP_HYPERV_SEND_IPI 161
+#define KVM_CAP_COALESCED_PIO 162
+#define KVM_CAP_HYPERV_ENLIGHTENED_VMCS 163
+#define KVM_CAP_EXCEPTION_PAYLOAD 164
++#define KVM_CAP_ARM_VM_IPA_SIZE 165 /* returns maximum IPA bits for a VM */
#ifdef KVM_CAP_IRQ_ROUTING
pgpQXXaIN4xWh.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi Stephen,
On Mon, Apr 10, 2017 at 01:52:42PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the kvm-arm tree got conflicts in:
>
> Documentation/virtual/kvm/api.txt
> include/uapi/linux/kvm.h
>
> between commits:
>
> a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
> 578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
>
> from the kvm tree and commit:
>
> 3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling ABI")
>
> from the kvm-arm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
The resolution looks good to me.
Thanks,
-Christoffer
>
> diff --cc Documentation/virtual/kvm/api.txt
> index 1a184843bf9c,3b4e76e5201e..
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@@ -4030,67 -4148,44 +4030,108 @@@ available, means that that the kernel c
> hashed page table MMU defined in Power ISA V3.00 (as implemented in
> the POWER9 processor), including in-memory segment tables.
>
> +8.5 KVM_CAP_MIPS_VZ
> +
> +Architectures: mips
> +
> +This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates
> that
> +it is available, means that full hardware assisted virtualization
> capabilities
> +of the hardware are available for use through KVM. An appropriate
> +KVM_VM_MIPS_* type must be passed to KVM_CREATE_VM to create a VM which
> +utilises it.
> +
> +If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
> +available, it means that the VM is using full hardware assisted
> virtualization
> +capabilities of the hardware. This is useful to check after creating a VM
> with
> +KVM_VM_MIPS_DEFAULT.
> +
> +The value returned by KVM_CHECK_EXTENSION should be compared against known
> +values (see below). All other values are reserved. This is to allow for the
> +possibility of other hardware assisted virtualization implementations which
> +may be incompatible with the MIPS VZ ASE.
> +
> + 0: The trap & emulate implementation is in use to run guest code in user
> +mode. Guest virtual memory segments are rearranged to fit the guest in
> the
> +user mode address space.
> +
> + 1: The MIPS VZ ASE is in use, providing full hardware assisted
> +virtualization, including standard guest virtual memory segments.
> +
> +8.6 KVM_CAP_MIPS_TE
> +
> +Architectures: mips
> +
> +This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates
> that
> +it is available, means that the trap & emulate implementation is available
> to
> +run guest code in user mode, even if KVM_CAP_MIPS_VZ indicates that hardware
> +assisted virtualisation is also available. KVM_VM_MIPS_TE (0) must be passed
> +to KVM_CREATE_VM to create a VM which utilises it.
> +
> +If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
> +available, it means that the VM is using trap & emulate.
> +
> +8.7 KVM_CAP_MIPS_64BIT
> +
> +Architectures: mips
> +
> +This capability indicates the supported architecture type of the guest,
> i.e. the
> +supported register and address width.
> +
> +The values returned when this capability is checked by KVM_CHECK_EXTENSION
> on a
> +kvm VM handle correspond roughly to the CP0_Config.AT register field, and
> should
> +be checked specifically against known values (see below). All other values
> are
> +reserved.
> +
> + 0: MIPS32 or microMIPS32.
> +Both registers and addresses are 32-bits wide.
> +It will only be possible to run 32-bit guest code.
> +
> + 1: MIPS64 or microMIPS64 with access only to 32-bit compatibility segments.
> +Registers are 64-bits wide, but addresses are 32-bits wide.
> +64-bit guest code may run but cannot access MIPS64 memory segments.
> +It will also be possible to run 32-bit guest code.
> +
> + 2: MIPS64 or microMIPS64 with access to all address segments.
> +Both registers and addresses are 64-bits wide.
> +It will be possible to run 64-bit or 32-bit guest code.
> +
> -8.5 KVM_CAP_ARM_USER_IRQ
> ++8.8 KVM_CAP_ARM_USER_IRQ
> +
> + Architectures: arm, arm64
> + This capability, if KVM_CHECK_EXTENSION indicates that it is available,
> means
> + that if userspace creates a VM without an in-kernel interrupt controller, it
> + will be notified of changes to the output level of in-kernel emulated
> devices,
> + which can generate virtual interrupts, presented to the VM.
> + For such VMs, on every return to userspace, the kernel
> + updates the vcpu's run->s.regs.device_irq_level field to represent the
> actual
> + output level of the device.
> +
> + Whenever kvm detects a change in the
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got conflicts in:
Documentation/virtual/kvm/api.txt
include/uapi/linux/kvm.h
between commits:
a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
from the kvm tree and commit:
3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling ABI")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/virtual/kvm/api.txt
index 1a184843bf9c,3b4e76e5201e..
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@@ -4030,67 -4148,44 +4030,108 @@@ available, means that that the kernel c
hashed page table MMU defined in Power ISA V3.00 (as implemented in
the POWER9 processor), including in-memory segment tables.
+8.5 KVM_CAP_MIPS_VZ
+
+Architectures: mips
+
+This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that
+it is available, means that full hardware assisted virtualization capabilities
+of the hardware are available for use through KVM. An appropriate
+KVM_VM_MIPS_* type must be passed to KVM_CREATE_VM to create a VM which
+utilises it.
+
+If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
+available, it means that the VM is using full hardware assisted virtualization
+capabilities of the hardware. This is useful to check after creating a VM with
+KVM_VM_MIPS_DEFAULT.
+
+The value returned by KVM_CHECK_EXTENSION should be compared against known
+values (see below). All other values are reserved. This is to allow for the
+possibility of other hardware assisted virtualization implementations which
+may be incompatible with the MIPS VZ ASE.
+
+ 0: The trap & emulate implementation is in use to run guest code in user
+mode. Guest virtual memory segments are rearranged to fit the guest in the
+user mode address space.
+
+ 1: The MIPS VZ ASE is in use, providing full hardware assisted
+virtualization, including standard guest virtual memory segments.
+
+8.6 KVM_CAP_MIPS_TE
+
+Architectures: mips
+
+This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that
+it is available, means that the trap & emulate implementation is available to
+run guest code in user mode, even if KVM_CAP_MIPS_VZ indicates that hardware
+assisted virtualisation is also available. KVM_VM_MIPS_TE (0) must be passed
+to KVM_CREATE_VM to create a VM which utilises it.
+
+If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
+available, it means that the VM is using trap & emulate.
+
+8.7 KVM_CAP_MIPS_64BIT
+
+Architectures: mips
+
+This capability indicates the supported architecture type of the guest, i.e.
the
+supported register and address width.
+
+The values returned when this capability is checked by KVM_CHECK_EXTENSION on
a
+kvm VM handle correspond roughly to the CP0_Config.AT register field, and
should
+be checked specifically against known values (see below). All other values are
+reserved.
+
+ 0: MIPS32 or microMIPS32.
+Both registers and addresses are 32-bits wide.
+It will only be possible to run 32-bit guest code.
+
+ 1: MIPS64 or microMIPS64 with access only to 32-bit compatibility segments.
+Registers are 64-bits wide, but addresses are 32-bits wide.
+64-bit guest code may run but cannot access MIPS64 memory segments.
+It will also be possible to run 32-bit guest code.
+
+ 2: MIPS64 or microMIPS64 with access to all address segments.
+Both registers and addresses are 64-bits wide.
+It will be possible to run 64-bit or 32-bit guest code.
+
-8.5 KVM_CAP_ARM_USER_IRQ
++8.8 KVM_CAP_ARM_USER_IRQ
+
+ Architectures: arm, arm64
+ This capability, if KVM_CHECK_EXTENSION indicates that it is available, means
+ that if userspace creates a VM without an in-kernel interrupt controller, it
+ will be notified of changes to the output level of in-kernel emulated devices,
+ which can generate virtual interrupts, presented to the VM.
+ For such VMs, on every return to userspace, the kernel
+ updates the vcpu's run->s.regs.device_irq_level field to represent the actual
+ output level of the device.
+
+ Whenever kvm detects a change in the device output level, kvm guarantees at
+ least one return to userspace before running the VM. This exit could either
+ be a KVM_EXIT_INTR or any other exit event, like KVM_EXIT_MMIO. This way,
+ userspace can always sample the device output level and re-compute the state
of
+ the userspace interrupt controller. Userspace should always check the state
+ of run->s
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
virt/kvm/irqchip.c
between commit:
c63cf538eb4b ("KVM: pass struct kvm to kvm_set_routing_entry")
from the kvm tree and commit:
995a0ee9809b ("KVM: arm/arm64: Enable MSI routing")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc virt/kvm/irqchip.c
index df99e9c3b64d,c6202199e505..
--- a/virt/kvm/irqchip.c
+++ b/virt/kvm/irqchip.c
@@@ -208,15 -208,19 +209,19 @@@ int kvm_set_irq_routing(struct kvm *kvm
goto out;
r = -EINVAL;
- if (ue->flags) {
- kfree(e);
- goto out;
+ switch (ue->type) {
+ case KVM_IRQ_ROUTING_MSI:
+ if (ue->flags & ~KVM_MSI_VALID_DEVID)
+ goto free_entry;
+ break;
+ default:
+ if (ue->flags)
+ goto free_entry;
+ break;
}
- r = setup_routing_entry(new, e, ue);
+ r = setup_routing_entry(kvm, new, e, ue);
- if (r) {
- kfree(e);
- goto out;
- }
+ if (r)
+ goto free_entry;
++ue;
}
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
Documentation/virtual/kvm/api.txt
between commit:
3713131345fb ("KVM: x86: add KVM_CAP_X2APIC_API")
from the kvm tree and commit:
76a10b86785c ("KVM: api: Pass the devid in the msi routing entry")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/virtual/kvm/api.txt
index 5237e1b2fd66,7a04216d7278..
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@@ -1479,14 -1486,20 +1486,25 @@@ struct kvm_irq_routing_msi
__u32 address_lo;
__u32 address_hi;
__u32 data;
- __u32 pad;
+ union {
+ __u32 pad;
+ __u32 devid;
+ };
};
+On x86, address_hi is ignored unless the KVM_X2APIC_API_USE_32BIT_IDS
+feature of KVM_CAP_X2APIC_API capability is enabled. If it is enabled,
+address_hi bits 31-8 provide bits 31-8 of the destination id. Bits 7-0 of
+address_hi must be zero.
+
+ devid: If KVM_MSI_VALID_DEVID is set, contains a unique device identifier
+for the device that wrote the MSI message.
+For PCI, this is usually a BFD identifier in the lower 16 bits.
+
+ The per-VM KVM_CAP_MSI_DEVID capability advertises the requirement to
+ provide the device ID. If this capability is not set, userland cannot
+ rely on the kernel to allow the KVM_MSI_VALID_DEVID flag being set.
+
struct kvm_irq_routing_s390_adapter {
__u64 ind_addr;
__u64 summary_addr;
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
include/uapi/linux/kvm.h
between commit:
3713131345fb ("KVM: x86: add KVM_CAP_X2APIC_API")
from the kvm tree and commit:
2b8ddd9337ee ("KVM: Extend struct kvm_msi to hold a 32-bit device ID")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/uapi/linux/kvm.h
index 4f8030e5b05d,d8c4c324cfae..
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -866,7 -866,7 +866,8 @@@ struct kvm_ppc_smmu_info
#define KVM_CAP_ARM_PMU_V3 126
#define KVM_CAP_VCPU_ATTRIBUTES 127
#define KVM_CAP_MAX_VCPU_ID 128
-#define KVM_CAP_MSI_DEVID 129
+#define KVM_CAP_X2APIC_API 129
++#define KVM_CAP_MSI_DEVID 130
#ifdef KVM_CAP_IRQ_ROUTING
RE: linux-next: manual merge of the kvm-arm tree with the kvm tree
> -Original Message- > From: Stephen Rothwell [mailto:s...@canb.auug.org.au] > Sent: Friday, October 16, 2015 11:53 AM > To: Christoffer Dall ; Marc Zyngier > ; Marcelo Tosatti ; Gleb > Natapov ; k...@vger.kernel.org > Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Wu, Feng > ; Paolo Bonzini ; Christian > Borntraeger ; Cornelia Huck > > Subject: linux-next: manual merge of the kvm-arm tree with the kvm tree > > I fixed it up (see below) and can carry the fix as necessary (no action > is required). Thanks Stephen! Thanks, Feng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
arch/x86/include/asm/kvm_host.h
between commit:
d84f1e0755ba ("KVM: make kvm_set_msi_irq() public")
from the kvm tree and commits:
8feb4a04dc75 ("KVM: Define a new interface kvm_intr_is_single_vcpu()")
8fc52eb9cee4 ("KVM: Add kvm_arch_vcpu_{un}blocking callbacks")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/include/asm/kvm_host.h
index 53deb2750bf6,b926137d591f..
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@@ -1256,9 -1232,7 +1256,13 @@@ int x86_set_memory_region(struct kvm *k
bool kvm_vcpu_is_reset_bsp(struct kvm_vcpu *vcpu);
bool kvm_vcpu_is_bsp(struct kvm_vcpu *vcpu);
+bool kvm_intr_is_single_vcpu(struct kvm *kvm, struct kvm_lapic_irq *irq,
+ struct kvm_vcpu **dest_vcpu);
+
+void kvm_set_msi_irq(struct kvm_kernel_irq_routing_entry *e,
+ struct kvm_lapic_irq *irq);
++
+ static inline void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu) {}
+ static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {}
+
#endif /* _ASM_X86_KVM_HOST_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the kvm-arm tree with the kvm tree
Thanks Stephen, it was (obviously) the right fix.
-Christoffer
On Wed, Nov 26, 2014 at 7:19 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the kvm-arm tree got a conflict in
> arch/ia64/kvm/kvm-ia64.c between commit 003f7de62589 ("KVM: ia64:
> remove") from the kvm tree and commit bf4bea8e9a90 ("kvm: fix
> kvm_is_mmio_pfn() and rename to kvm_is_reserved_pfn()") from the
> kvm-arm tree.
>
> I fixed it up (the former removed the file, so I did that) and can
> carry the fix as necessary (no action is required).
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in
arch/ia64/kvm/kvm-ia64.c between commit 003f7de62589 ("KVM: ia64:
remove") from the kvm tree and commit bf4bea8e9a90 ("kvm: fix
kvm_is_mmio_pfn() and rename to kvm_is_reserved_pfn()") from the
kvm-arm tree.
I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpiXNtxsocFG.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in
virt/kvm/eventfd.c between commit 29f1b65b5984 ("KVM: EVENTFD: Remove
inclusion of irq.h") from the kvm tree and commit 0ba09511ddc3 ("KVM:
EVENTFD: remove inclusion of irq.h") from the kvm-arm tree.
I fixed it up (I used the kvm tree version) and can carry the fix as
necessary (no action is required).
git diff
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: linux-next: manual merge of the kvm-arm tree with the kvm tree
On Thu, Sep 18 2014 at 04:52:26 AM, Stephen Rothwell
wrote:
> Hi all,
>
> Today's linux-next merge of the kvm-arm tree got a conflict in
> virt/kvm/arm/vgic.c between commit c06a841bf363 ("KVM: ARM: vgic:
> register kvm_device_ops dynamically") from the kvm tree and commit
> de56fb1923ca ("KVM: vgic: declare probe function pointer as const")
> from the kvm-arm tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks Stephen.
M.
--
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in
virt/kvm/arm/vgic.c between commit c06a841bf363 ("KVM: ARM: vgic:
register kvm_device_ops dynamically") from the kvm tree and commit
de56fb1923ca ("KVM: vgic: declare probe function pointer as const")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc virt/kvm/arm/vgic.c
index 3ee3ce06bbec,efe6eee2e7eb..
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@@ -1993,81 -2070,3 +1993,81 @@@ static struct kvm_device_ops kvm_arm_vg
.get_attr = vgic_get_attr,
.has_attr = vgic_has_attr,
};
+
+static void vgic_init_maintenance_interrupt(void *info)
+{
+ enable_percpu_irq(vgic->maint_irq, 0);
+}
+
+static int vgic_cpu_notify(struct notifier_block *self,
+ unsigned long action, void *cpu)
+{
+ switch (action) {
+ case CPU_STARTING:
+ case CPU_STARTING_FROZEN:
+ vgic_init_maintenance_interrupt(NULL);
+ break;
+ case CPU_DYING:
+ case CPU_DYING_FROZEN:
+ disable_percpu_irq(vgic->maint_irq);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block vgic_cpu_nb = {
+ .notifier_call = vgic_cpu_notify,
+};
+
+static const struct of_device_id vgic_ids[] = {
+ { .compatible = "arm,cortex-a15-gic", .data = vgic_v2_probe, },
+ { .compatible = "arm,gic-v3", .data = vgic_v3_probe, },
+ {},
+};
+
+int kvm_vgic_hyp_init(void)
+{
+ const struct of_device_id *matched_id;
- int (*vgic_probe)(struct device_node *,const struct vgic_ops **,
++ const int (*vgic_probe)(struct device_node *,const struct vgic_ops **,
+const struct vgic_params **);
+ struct device_node *vgic_node;
+ int ret;
+
+ vgic_node = of_find_matching_node_and_match(NULL,
+ vgic_ids, &matched_id);
+ if (!vgic_node) {
+ kvm_err("error: no compatible GIC node found\n");
+ return -ENODEV;
+ }
+
+ vgic_probe = matched_id->data;
+ ret = vgic_probe(vgic_node, &vgic_ops, &vgic);
+ if (ret)
+ return ret;
+
+ ret = request_percpu_irq(vgic->maint_irq, vgic_maintenance_handler,
+ "vgic", kvm_get_running_vcpus());
+ if (ret) {
+ kvm_err("Cannot register interrupt %d\n", vgic->maint_irq);
+ return ret;
+ }
+
+ ret = __register_cpu_notifier(&vgic_cpu_nb);
+ if (ret) {
+ kvm_err("Cannot register vgic CPU notifier\n");
+ goto out_free_irq;
+ }
+
+ /* Callback into for arch code for setup */
+ vgic_arch_setup(vgic);
+
+ on_each_cpu(vgic_init_maintenance_interrupt, NULL, 1);
+
+ return kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
+ KVM_DEV_TYPE_ARM_VGIC_V2);
+
+out_free_irq:
+ free_percpu_irq(vgic->maint_irq, kvm_get_running_vcpus());
+ return ret;
+}
signature.asc
Description: PGP signature
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in
arch/arm64/include/asm/kvm_host.h between commit 656473003bc7 ("KVM:
forward declare structs in kvm_types.h") from the kvm tree and commit
6951e48bff0b ("KVM: ARM/arm64: fix non-const declaration of function
returning const") from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm64/include/asm/kvm_host.h
index be9970a59497,50431d36732b..
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@@ -43,7 -41,8 +43,7 @@@
#define KVM_VCPU_MAX_FEATURES 3
- int kvm_target_cpu(void);
-struct kvm_vcpu;
+ int __attribute_const__ kvm_target_cpu(void);
int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
int kvm_arch_dev_ioctl_check_extension(long ext);
signature.asc
Description: PGP signature
