[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1e0a03b4-1fb6-cbe2-fb7a-8ed39341a187@arm.com>
Date: Mon, 5 Aug 2019 14:14:08 +0100
From: Steven Price <steven.price@....com>
To: Marc Zyngier <maz@...nel.org>
Cc: kvm@...r.kernel.org,
Radim Krčmář <rkrcmar@...hat.com>,
Catalin Marinas <catalin.marinas@....com>,
Suzuki K Pouloze <suzuki.poulose@....com>,
linux-doc@...r.kernel.org, Russell King <linux@...linux.org.uk>,
linux-kernel@...r.kernel.org, James Morse <james.morse@....com>,
linux-arm-kernel@...ts.infradead.org,
Paolo Bonzini <pbonzini@...hat.com>,
Will Deacon <will@...nel.org>, kvmarm@...ts.cs.columbia.edu,
Julien Thierry <julien.thierry.kdev@...il.com>
Subject: Re: [PATCH 3/9] KVM: arm64: Implement PV_FEATURES call
On 03/08/2019 12:21, Marc Zyngier wrote:
> On Fri, 2 Aug 2019 15:50:11 +0100
> Steven Price <steven.price@....com> wrote:
>
>> This provides a mechanism for querying which paravirtualized features
>> are available in this hypervisor.
>>
>> Also add the header file which defines the ABI for the paravirtualized
>> clock features we're about to add.
>>
>> Signed-off-by: Steven Price <steven.price@....com>
>> ---
>> arch/arm64/include/asm/pvclock-abi.h | 20 ++++++++++++++++++++
>> include/linux/arm-smccc.h | 14 ++++++++++++++
>> virt/kvm/arm/hypercalls.c | 9 +++++++++
>> 3 files changed, 43 insertions(+)
>> create mode 100644 arch/arm64/include/asm/pvclock-abi.h
>>
>> diff --git a/arch/arm64/include/asm/pvclock-abi.h b/arch/arm64/include/asm/pvclock-abi.h
>> new file mode 100644
>> index 000000000000..1f7cdc102691
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/pvclock-abi.h
>> @@ -0,0 +1,20 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright (C) 2019 Arm Ltd. */
>> +
>> +#ifndef __ASM_PVCLOCK_ABI_H
>> +#define __ASM_PVCLOCK_ABI_H
>> +
>> +/* The below structures and constants are defined in ARM DEN0057A */
>> +
>> +struct pvclock_vcpu_stolen_time_info {
>> + __le32 revision;
>> + __le32 attributes;
>> + __le64 stolen_time;
>> + /* Structure must be 64 byte aligned, pad to that size */
>> + u8 padding[48];
>> +} __packed;
>> +
>> +#define PV_VM_TIME_NOT_SUPPORTED -1
>
> Isn't the intent for this to be the same value as
> SMCCC_RET_NOT_SUPPORTED?
Yes it is, I guess there's not much point defining it again.
>> +#define PV_VM_TIME_INVALID_PARAMETERS -2
>
> It overlaps with SMCCC_RET_NOT_REQUIRED. Is that a problem? Should we
> consider a spec change for this?
Actually INVALID_PARAMETERS is only for Live Physical Time, since we're
not implementing it here, this can go as well.
Thanks,
Steve
Powered by blists - more mailing lists