qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH v3 2/5] target/arm: Fill in ARMISARegisters for kv


From: Richard Henderson
Subject: Re: [Qemu-arm] [PATCH v3 2/5] target/arm: Fill in ARMISARegisters for kvm64
Date: Mon, 12 Nov 2018 15:09:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0

On 11/12/18 12:37 PM, Peter Maydell wrote:
> On 8 November 2018 at 17:52, Richard Henderson
> <address@hidden> wrote:
>> Signed-off-by: Richard Henderson <address@hidden>
>> ---
> 
>>      /* Old kernels may not know about the PREFERRED_TARGET ioctl: however
>>       * we know these will only support creating one kind of guest CPU,
>>       * which is its preferred CPU type. Fortunately these old kernels
>> @@ -474,8 +497,71 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures 
>> *ahcf)
>>      ahcf->target = init.target;
>>      ahcf->dtb_compatible = "arm,arm-v8";
>>
>> +    err = read_sys_reg64(fdarray[2], &ahcf->isar.id_aa64pfr0,
>> +                         ARM64_SYS_REG(3, 0, 0, 4, 0));
>> +    if (unlikely(err < 0)) {
>> +        /*
>> +         * Before v4.15, the kernel only exposed a limited number of system
>> +         * registers, not including any of the interesting AArch64 ID regs.
>> +         * For the most part we could leave these fields as zero with 
>> minimal
>> +         * effect, since this does not affect the values seen by the guest.
> 
> These older kernels do implement reading of id_isar0 through
> id_isar5, though -- we could read and use those values rather than
> leaving them zero.

But without id_aa64pfr0, we don't know if id_isar0 et al have UNKNOWN values
due to aa32 mode not being present.  E.g. run a 4.8 kernel on a thunderx1 cpu.

>> +        ahcf->isar.id_aa64pfr0 = 0x00000011; /* EL1&0, AArch64 only */
>> +        err = 0;
> 
> Doesn't this code path leave everything except id_aa64pfr0 as
> zero, thus leaving us with the "could cause problems down the
> line" situation ?

The other id_aa64* register fields are all extensions to v8.0, so they should
be zero.  I am of course assuming that AdvSIMD is present, otherwise qemu
itself probably have failed before now.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]