Re: [PATCH 1/2] arm64: qcom: Add define for ARMv8 implementer (MIDR)

2015-06-22 Thread Timur Tabi

Catalin Marinas wrote:

So if the second patch is no longer needed, what's using this patch? I
would defer merging it until actually required in some part of the
kernel.


Fair enough.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line unsubscribe kvm in


Re: [PATCH] arm64/kvm: Add generic v8 KVM target

2015-06-19 Thread Timur Tabi

On 06/17/2015 04:00 AM, Suzuki K. Poulose wrote:

  genericv8_target_table);
kvm_register_target_sys_reg_table(KVM_ARM_TARGET_XGENE_POTENZA,
  genericv8_target_table);
+   kvm_register_target_sys_reg_table(KVM_ARM_TARGET_GENERIC_V8,
+ genericv8_target_table);



Shouldn't you also remove all of the previous lines that return 
genericv8_target_table?


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line unsubscribe kvm in


Re: [PATCH 1/2] arm64: qcom: Add define for ARMv8 implementer (MIDR)

2015-06-19 Thread Timur Tabi

On 06/15/2015 05:59 AM, Catalin Marinas wrote:

I think this patch together with the second one could go through the kvm
tree. For the core arm64 part:

Acked-by: Catalin Marinascatalin.mari...@arm.com


Suzuki Poulose posted a patch that adds generic support for ARMv8 KVM 
targets.  I want to drop my second patch, so can we pick up this first 
patch through the ARM tree?


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line unsubscribe kvm in


[PATCH 1/2] arm64: qcom: Add define for ARMv8 implementer (MIDR)

2015-06-12 Thread Timur Tabi
From: Shanker Donthineni shank...@codeaurora.org

This patch adds define for Qualcomm Technologies ARMv8 CPU
implementer ID 0x51 and part number for Kryo in asm/cputype.h.

Signed-off-by: Shanker Donthineni shank...@codeaurora.org
Signed-off-by: Timur Tabi ti...@codeaurora.org
---
 arch/arm64/include/asm/cputype.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index a84ec60..6978764 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -64,6 +64,7 @@
 
 #define ARM_CPU_IMP_ARM0x41
 #define ARM_CPU_IMP_APM0x50
+#define ARM_CPU_IMP_QCOM   0x51
 
 #define ARM_CPU_PART_AEM_V80xD0F
 #define ARM_CPU_PART_FOUNDATION0xD00
@@ -84,6 +85,9 @@
 #define SCTLR_EL1_CP15BEN  (0x1  5)
 #define SCTLR_EL1_SED  (0x1  8)
 
+#define QCOM_CPU_PART_MASK 0xF00
+#define QCOM_CPU_PART_KRYO 0x200
+
 #ifndef __ASSEMBLY__
 
 /*
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/2] arm64: KVM: Add VCPU support for Qualcomm Technologies Kryo ARMv8 CPU

2015-06-12 Thread Timur Tabi
From: Shanker Donthineni shank...@codeaurora.org

This patch enables assignment of 32/64bit guest VCPU to
Qualcomm Technologies ARMv8 CPU. Added KVM_ARM_TARGET_QCOM_KRYO
to the KVM target list and modified vm_target_cpu() to return
KVM_ARM_TARGET_QCOM_KRYO when CPU running in AArch64 mode.

Signed-off-by: Shanker Donthineni shank...@codeaurora.org
Signed-off-by: Timur Tabi ti...@codeaurora.org
---
 arch/arm64/include/uapi/asm/kvm.h| 3 ++-
 arch/arm64/kvm/guest.c   | 6 ++
 arch/arm64/kvm/sys_regs_generic_v8.c | 2 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/uapi/asm/kvm.h 
b/arch/arm64/include/uapi/asm/kvm.h
index d268320..426933e 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -59,8 +59,9 @@ struct kvm_regs {
 #define KVM_ARM_TARGET_CORTEX_A57  2
 #define KVM_ARM_TARGET_XGENE_POTENZA   3
 #define KVM_ARM_TARGET_CORTEX_A53  4
+#define KVM_ARM_TARGET_QCOM_KRYO   5
 
-#define KVM_ARM_NUM_TARGETS5
+#define KVM_ARM_NUM_TARGETS6
 
 /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
 #define KVM_ARM_DEVICE_TYPE_SHIFT  0
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 9535bd5..836cf16 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -291,6 +291,12 @@ int __attribute_const__ kvm_target_cpu(void)
return KVM_ARM_TARGET_XGENE_POTENZA;
};
break;
+   case ARM_CPU_IMP_QCOM:
+   switch (part_number  QCOM_CPU_PART_MASK) {
+   case QCOM_CPU_PART_KRYO:
+   return KVM_ARM_TARGET_QCOM_KRYO;
+   }
+   break;
};
 
return -EINVAL;
diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c 
b/arch/arm64/kvm/sys_regs_generic_v8.c
index 475fd29..3712ea8 100644
--- a/arch/arm64/kvm/sys_regs_generic_v8.c
+++ b/arch/arm64/kvm/sys_regs_generic_v8.c
@@ -94,6 +94,8 @@ static int __init sys_reg_genericv8_init(void)
  genericv8_target_table);
kvm_register_target_sys_reg_table(KVM_ARM_TARGET_XGENE_POTENZA,
  genericv8_target_table);
+   kvm_register_target_sys_reg_table(KVM_ARM_TARGET_QCOM_KRYO,
+ genericv8_target_table);
 
return 0;
 }
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v11 8/8] PPC: Don't use hardcoded opcode for ePAPR hcall invocation

2012-07-02 Thread Timur Tabi
Scott Wood wrote:

 Hmm.  The comment says, XER, CTR, and LR are currently listed as
 clobbers because it's uncertain whether they will be clobbered.  Maybe
 it dates back to when the ABI was still being discussed?  Timur, do you
 recall?

Nope, sorry.  I'm sure we discussed this and looked at the code.  My guess
is that we weren't certain what the compiler was going to do at the time.

I'm still a little confused.  Which inline assembly code is clobbering LR?
 Are you talking about the BL instruction, which wasn't there before?

-- 
Timur Tabi
Linux kernel developer at Freescale

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v11 8/8] PPC: Don't use hardcoded opcode for ePAPR hcall invocation

2012-07-02 Thread Timur Tabi
Scott Wood wrote:
   I'm still a little confused.  Which inline assembly code is clobbering LR?
   Are you talking about the BL instruction, which wasn't there before?

 Yes, I didn't realize that LR had been in the clobber list before that.

So are you saying that it was wrong before, but it's correct now?

-- 
Timur Tabi
Linux kernel developer at Freescale

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v11 8/8] PPC: Don't use hardcoded opcode for ePAPR hcall invocation

2012-07-02 Thread Timur Tabi
Scott Wood wrote:
  So are you saying that it was wrong before, but it's correct now?

 Not really *wrong* before, but unnecessary.

In that case, my code was really just ahead of its time. :-)

-- 
Timur Tabi
Linux kernel developer at Freescale

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v11 8/8] PPC: Don't use hardcoded opcode for ePAPR hcall invocation

2012-07-02 Thread Timur Tabi
Scott Wood wrote:
   I'm still a little confused.  Which inline assembly code is clobbering LR?
   Are you talking about the BL instruction, which wasn't there before?

 Yes, I didn't realize that LR had been in the clobber list before that.

So are you saying that it was wrong before, but it's correct now?

-- 
Timur Tabi
Linux kernel developer at Freescale

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v11 8/8] PPC: Don't use hardcoded opcode for ePAPR hcall invocation

2012-07-02 Thread Timur Tabi
Scott Wood wrote:
  So are you saying that it was wrong before, but it's correct now?

 Not really *wrong* before, but unnecessary.

In that case, my code was really just ahead of its time. :-)

-- 
Timur Tabi
Linux kernel developer at Freescale

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [linuxppc-release] [PATCH v11 6/8] PPC: select EPAPR_PARAVIRT for all users of epapr hcalls

2012-06-22 Thread Timur Tabi
Stuart Yoder wrote:
 -new in v11-- this patch is needed so the dependencies are correct
  for all users of epapr hcalls, without it there will be build issues
  after hardcoded opcodes for hcalls are removed

This should have been part of the patch description.

-- 
Timur Tabi
Linux kernel developer at Freescale

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [linuxppc-release] [PATCH v11 6/8] PPC: select EPAPR_PARAVIRT for all users of epapr hcalls

2012-06-22 Thread Timur Tabi
Stuart Yoder wrote:
 -new in v11-- this patch is needed so the dependencies are correct
  for all users of epapr hcalls, without it there will be build issues
  after hardcoded opcodes for hcalls are removed

This should have been part of the patch description.

-- 
Timur Tabi
Linux kernel developer at Freescale

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html