On 6/30/19 11:49 AM, Jan Kiszka wrote:
> On 30.06.19 12:18, Jan Kiszka wrote:
>> On 30.06.19 11:34, Jan Kiszka wrote:
>>> On 30.06.19 00:42, Marc Zyngier wrote:
>>>> On Sat, 29 Jun 2019 19:09:37 +0200
>>>> Jan Kiszka <jan.kiszka@xxxxxx> wrote:
>>>>> However, as the Raspberry kernel is not yet ready for 64-bit (and
>>>>> upstream is not in sight), I had to use legacy 32-bit mode. And there we
>>>>> stumble over the core detection. This little patch made it work, though:
>>>>>
>>>>> diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
>>>>> index 2b8de885b2bf..01606aad73cc 100644
>>>>> --- a/arch/arm/kvm/guest.c
>>>>> +++ b/arch/arm/kvm/guest.c
>>>>> @@ -290,6 +290,7 @@ int __attribute_const__ kvm_target_cpu(void)
>>>>> case ARM_CPU_PART_CORTEX_A7:
>>>>> return KVM_ARM_TARGET_CORTEX_A7;
>>>>> case ARM_CPU_PART_CORTEX_A15:
>>>>> + case ARM_CPU_PART_CORTEX_A72:
>>>>> return KVM_ARM_TARGET_CORTEX_A15;
>>>>> default:
>>>>> return -EINVAL;
>>>>>
>>>>> That raises the question if this is hack or a valid change and if there
>>>>> is general interest in mapping 64-bit cores on 32-bit if they happen to
>>>>> run in 32-bit mode.
>>>>
>>>> The real thing to do here would be to move to a generic target, much
>>>> like we did on the 64bit side. Could you investigate that instead? It
>>>> would also allow KVM to be used on other 32bit cores such as
>>>> A12/A17/A32.
>>>
>>> You mean something like KVM_ARM_TARGET_GENERIC_V8? Need to study that...
>>>
>>
>> Hmm, looking at what KVM_ARM_TARGET_CORTEX_A7 and ..._A15 differentiates, I
>> found nothing so far:
>>
>> kvm_reset_vcpu:
>> switch (vcpu->arch.target) {
>> case KVM_ARM_TARGET_CORTEX_A7:
>> case KVM_ARM_TARGET_CORTEX_A15:
>> reset_regs = &cortexa_regs_reset;
>> vcpu->arch.midr = read_cpuid_id();
>> break;
>>
>> And arch/arm/kvm/coproc_a15.c looks like a copy of coproc_a7.c, just with some
>> symbols renamed.
>
> OK, found it: The reset values of SCTLR differ, in one bit. A15 starts with
> branch prediction (11) off, A7 with that feature enabled. Quite some boilerplate
> code for managing a single bit.
>
> For a generic target, can we simply assume A15 reset behaviour?
IIUC, it'd work only for ARCH_VIRT guest, which is known not to touch IMP_DEF
registers. Unfortunately, other variants of guests (ARCH_VEXPRESS?) might touch
such registers, for instance, l2ctlr is often used for querying number of populated
cpus, and it might not be present at all on v8. Also, content of IMP_DEF register
is not fixed and meaning of the bits may wary between different implementations, so
guests may react differently.
Just my 2p.
Cheers
Vladimir
>
> Jan
> _______________________________________________
> kvmarm mailing list
> kvmarm@xxxxxxxxxxxxxxxxxxxxx
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
