On 2013-07-15 15:37, Anup Patel wrote:
> Hi Marc,
>
> On Mon, Jul 15, 2013 at 7:51 PM, Alexander Graf <agraf@xxxxxxx>
> wrote:
>>
>> On 15.07.2013, at 16:04, Anup Patel wrote:
>>
>>> On Mon, Jul 15, 2013 at 6:32 PM, Alexander Graf <agraf@xxxxxxx>
>>> wrote:
>>>>
>>>> On 15.07.2013, at 14:56, Anup Patel wrote:
>>>>
>>>>> Hi Marc,
>>>>>
>>>>> On Mon, Jul 15, 2013 at 6:09 PM, Marc Zyngier
>>>>> <marc.zyngier@xxxxxxx> wrote:
>>>>>> Hi Anup,
>>>>>>
>>>>>> On 15/07/13 12:46, Anup Patel wrote:
>>>>>>> This patch allows us to have X-Gene guest VCPU when using
>>>>>>> KVM arm64 on APM X-Gene host.
>>>>>>>
>>>>>>> We add KVM_ARM_TARGET_XGENE_V8 for X-Gene compatible guest VCPU
>>>>>>> and we return KVM_ARM_TARGET_XGENE_V8 in kvm_target_cpu() when
>>>>>>> running on X-Gene host.
>>>>>>>
>>>>>>> Signed-off-by: Anup Patel <anup.patel@xxxxxxxxxx>
>>>>>>> Signed-off-by: Pranavkumar Sawargaonkar
>>>>>>> <pranavkumar@xxxxxxxxxx>
>>>>>>> ---
>>>>>>> arch/arm64/include/uapi/asm/kvm.h | 3 ++-
>>>>>>> arch/arm64/kvm/guest.c | 34
>>>>>>> ++++++++++++++++++++++------------
>>>>>>> arch/arm64/kvm/sys_regs_generic_v8.c | 3 +++
>>>>>>> 3 files changed, 27 insertions(+), 13 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm64/include/uapi/asm/kvm.h
>>>>>>> b/arch/arm64/include/uapi/asm/kvm.h
>>>>>>> index 5031f42..8194707 100644
>>>>>>> --- a/arch/arm64/include/uapi/asm/kvm.h
>>>>>>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>>>>>>> @@ -55,8 +55,9 @@ struct kvm_regs {
>>>>>>> #define KVM_ARM_TARGET_AEM_V8 0
>>>>>>> #define KVM_ARM_TARGET_FOUNDATION_V8 1
>>>>>>> #define KVM_ARM_TARGET_CORTEX_A57 2
>>>>>>> +#define KVM_ARM_TARGET_XGENE_V8 3
>>>>>>>
>>>>>>> -#define KVM_ARM_NUM_TARGETS 3
>>>>>>> +#define KVM_ARM_NUM_TARGETS 4
>>>>>>>
>>>>>>> /* 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 2c3ff67..e99b0a5 100644
>>>>>>> --- a/arch/arm64/kvm/guest.c
>>>>>>> +++ b/arch/arm64/kvm/guest.c
>>>>>>> @@ -207,19 +207,29 @@ int __attribute_const__
>>>>>>> kvm_target_cpu(void)
>>>>>>> unsigned long implementor = read_cpuid_implementor();
>>>>>>> unsigned long part_number = read_cpuid_part_number();
>>>>>>>
>>>>>>> - if (implementor != ARM_CPU_IMP_ARM)
>>>>>>> - return -EINVAL;
>>>>>>> -
>>>>>>> - switch (part_number) {
>>>>>>> - case ARM_CPU_PART_AEM_V8:
>>>>>>> - return KVM_ARM_TARGET_AEM_V8;
>>>>>>> - case ARM_CPU_PART_FOUNDATION:
>>>>>>> - return KVM_ARM_TARGET_FOUNDATION_V8;
>>>>>>> - case ARM_CPU_PART_CORTEX_A57:
>>>>>>> - /* Currently handled by the generic backend */
>>>>>>> - return KVM_ARM_TARGET_CORTEX_A57;
>>>>>>> + switch (implementor) {
>>>>>>> + case ARM_CPU_IMP_ARM:
>>>>>>> + switch (part_number) {
>>>>>>> + case ARM_CPU_PART_AEM_V8:
>>>>>>> + return KVM_ARM_TARGET_AEM_V8;
>>>>>>> + case ARM_CPU_PART_FOUNDATION:
>>>>>>> + return KVM_ARM_TARGET_FOUNDATION_V8;
>>>>>>> + case ARM_CPU_PART_CORTEX_A57:
>>>>>>> + return KVM_ARM_TARGET_CORTEX_A57;
>>>>>>> + default:
>>>>>>> + return -EINVAL;
>>>>>>> + }
>>>>>>> + break;
>>>>>>> + case ARM_CPU_IMP_APM:
>>>>>>> + switch (part_number) {
>>>>>>> + case APM_CPU_PART_POTENZA:
>>>>>>> + return KVM_ARM_TARGET_XGENE_V8;
>>>>>>
>>>>>> Why don't we have KVM_ARM_TARGET_XGENE_POTENZA (or something
>>>>>> similar)
>>>>>> instead? I don't expect all the X-Gene CPUs to be the same
>>>>>> forever...
>>>>>
>>>>> OK, I will rename it to KVM_ARM_TARGET_XGENE_POTENZA.
>>>>>
>>>>> Does this mean that with every new ARM64 CPU we will have to add
>>>>> a new
>>>>> target for KVM ARM64 ?
>>>>
>>>> Only for different core types, no? Any Cortex-A57 should still
>>>> behave the same.
>>>>
>>>>> If so then I think the list of targets will grow very fast.
>>>>>
>>>>> I also realized that if we add a new target type in KVM ARM64
>>>>> then we have
>>>>> to also update KVMTOOL to use the new target else KVMTOOL fails
>>>>> to
>>>>> recognize the target provided by KVM ARM64.
>>>>
>>>> Right. It might make sense to have a fetch mechanism for the host
>>>> cpu part. So you can ask KVM for the host cpu type and pass that
>>>> back in here.
>>>>
>>>>> Do you think we can have KVM_ARM_TARGET_xxx to represent a common
>>>>> target for a family of CPUs from given ARM64 vendor?
>>>>
>>>> Anything that is compatible is compatible :). I don't know the
>>>> product roadmaps for X-Gene cores, but you will want to make the
>>>> field here as coarse grained as possible, while maintaining the
>>>> guarantee that a guest still behaves the same.
>>>
>>> Actually, I don't see X-Gene cores changing in-terms of register
>>> interface
>>> available to EL1 and EL0 in near future. This is the reason why I
>>> had named
>>> the target as KVM_ARM_TARGET_XGENE_V8.
>>
>> So where does the v8 come from? Is there any non-ARMv8 XGene? If
>> not, this is v1 really, right? What if we just call it v1 instead?
>> Then when a new core comes up that needs different treatment, we
>> create a new target.
>>
>> But this really is Marc's call.
>
> I like Alex's suggestion.
>
> How about having KVM_ARM_TARGET_XGENE_V1 now and
> KVM_ARM_TARGET_XGENE_V2 in future ?
How will we know for sure which CPU implements which version of the
micro-architecture?
M.
--
Fast, cheap, reliable. Pick two.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
