Re: [PATCH 3/5] kvm: arm64: Limit PMU version to ARMv8.1

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

 



Hi Marc,

On 2/19/20 9:46 AM, Marc Zyngier wrote:
> On 2020-02-18 17:43, James Morse wrote:
>> Hi Marc,
>>
>> On 16/02/2020 18:53, Marc Zyngier wrote:
>>> Our PMU code is only implementing the ARMv8.1 features, so let's
>>> stick to this when reporting the feature set to the guest.
>>
>>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>>> index 682fedd7700f..06b2d0dc6c73 100644
>>> --- a/arch/arm64/kvm/sys_regs.c
>>> +++ b/arch/arm64/kvm/sys_regs.c
>>> @@ -1093,6 +1093,11 @@ static u64 read_id_reg(const struct kvm_vcpu
>>> *vcpu,
>>>                   FEATURE(ID_AA64ISAR1_GPA) |
>>>                   FEATURE(ID_AA64ISAR1_GPI));
>>>          break;
>>> +    case SYS_ID_AA64DFR0_EL1:
>>> +        /* Limit PMU to ARMv8.1 */
>>
>> Not just limit, but upgrade too! (force?)
>> This looks safe because ARMV8_PMU_EVTYPE_EVENT always includes the
>> extra bits this added, and the register is always trapped.
> 
> That's definitely not what I intended! Let me fix that one.

What goes wrong?

The register description says to support v8.1 you need:
| Extended 16-bit PMEVTYPER<n>_EL0.evtCount field
| If EL2 is implemented, the MDCR_EL2.HPMD control bit

It looks like the extended PMEVTYPER would work via the emulation, and
EL2 guests are totally crazy.

Is the STALL_* bits in ARMv8.1-PMU the problem, ... or the extra work
for NV?


>> The PMU version is also readable via ID_DFR0_EL1.PerfMon, should that
>> be sanitised to be the same? (I don't think we've hidden an aarch64
>> feature that also existed in aarch32 before).
> 
> Indeed, yet another oversight. I'll fix that too.

(Weird variation in the aarch32 and aarch64 ID registers isn't something
I care about ... who would ever look at both?)



Thanks,

James
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm




[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux