lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6f217836-45fb-8833-7bb1-5dc822826f56@redhat.com>
Date:   Thu, 24 Mar 2022 12:07:34 +0800
From:   Gavin Shan <gshan@...hat.com>
To:     Oliver Upton <oupton@...gle.com>
Cc:     kvmarm@...ts.cs.columbia.edu, maz@...nel.org,
        linux-kernel@...r.kernel.org, eauger@...hat.com,
        shan.gavin@...il.com, Jonathan.Cameron@...wei.com,
        pbonzini@...hat.com, vkuznets@...hat.com, will@...nel.org
Subject: Re: [PATCH v5 03/22] KVM: arm64: Support SDEI_VERSION hypercall

Hi Oliver,

On 3/24/22 12:31 AM, Oliver Upton wrote:
> On Wed, Mar 23, 2022 at 08:46:40PM +0800, Gavin Shan wrote:
>> On 3/23/22 2:04 AM, Oliver Upton wrote:
>>> On Tue, Mar 22, 2022 at 04:06:51PM +0800, Gavin Shan wrote:
>>>> This supports SDEI_VERSION hypercall by returning v1.1, which is
>>>> the specification version we're following. The vendor is set to
>>>> 'KVM'.
>>>>
>>>> Signed-off-by: Gavin Shan <gshan@...hat.com>
>>>> ---
>>>>    arch/arm64/kvm/sdei.c | 10 ++++++++++
>>>>    1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/kvm/sdei.c b/arch/arm64/kvm/sdei.c
>>>> index 8a9b477b8977..5a3a64cd6e84 100644
>>>> --- a/arch/arm64/kvm/sdei.c
>>>> +++ b/arch/arm64/kvm/sdei.c
>>>> @@ -118,6 +118,14 @@ static bool remove_all_vcpu_events(struct kvm_vcpu *vcpu,
>>>>    	return pending;
>>>>    }
>>>> +static unsigned long hypercall_version(struct kvm_vcpu *vcpu)
>>>> +{
>>>> +	/* v1.1 and the vendor is KVM */
>>>> +	return (1UL << SDEI_VERSION_MAJOR_SHIFT) |
>>>> +	       (1UL << SDEI_VERSION_MINOR_SHIFT) |
>>>> +	       0x4b564d;
>>>
>>> It looks like the SDEI specification states that the vendor-defined
>>> version number is 32 bits. Could we just use one of the
>>> ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_{0,3} values instead?
>>>
>>> ASCII 'KVM' is neat, but in reality guest software will just throw it in
>>> a macro regardless. Might as well use one of the values we've already
>>> trained it to use :-)
>>>
>>> Also, it would appear that guest discovery of SDEI relies upon KVM
>>> reporting a valid SDEI version. IMO, this patch should come at the very
>>> end when KVM actually implements SDEI.
>>>
>>
>> Yeah, I was sticky to the pattern of "KVM". However, I think it's good
>> to reuse the existing one. Lets use ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_2
>> if you agree. Its first two characters are "VM" at least.
> 
> Sounds fine to me. The only other nit I'd say is we should define a
> macro for it too, something like:
> 
>    #define KVM_SDEI_VENDOR	ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_2
> 

Agreed, and the macro will be put into arch/arm64/include/asm/kvm_sdei.h.
arch/arm64/include/uapi/asm/kvm_sdei_state.h isn't the right place because
the dependent macro ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_2 isn't exposed by
ABI.

Thanks,
Gavin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ