Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp8557092rwb; Thu, 24 Nov 2022 00:53:23 -0800 (PST) X-Google-Smtp-Source: AA0mqf6eKuolHgqdilOV7mVroHS4kVq7NmApwqOQJuXiT0+xd4DLJmvhE58u7TNcQ46LlFBEOVF0 X-Received: by 2002:a63:c65:0:b0:476:db6f:d436 with SMTP id 37-20020a630c65000000b00476db6fd436mr29889650pgm.394.1669280002977; Thu, 24 Nov 2022 00:53:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669280002; cv=none; d=google.com; s=arc-20160816; b=Ae9fCUgtKtpTMBJjHvKSY4mhVH9HUy02R/WbYoiTMdbD+Pz9I8oNoxEGM2/yD5OSw6 qaWvr3SWwHlQIE4kI2l3DpOlIcUm9deg0MYzgusDwOiwikCN3ZCj5x3YM0t5BAof84CC 9c3yencudwcXHMQGg0U4j13nY9KL3aNsoXH7qrGwXzv1VqhmlT+/6N7uFBteC4uok1F9 lUsTfg5CZjxla2ODlx7pJaSxmD8OI7fFHqNzkl38Oe/FAwjcWgCu8TQt/vK+oBOY9Hm8 7LOpbpAOgIaYW4GHfScbqHRneC7j9IBYHcW5OadhslXgQwHFHbFz9Xa6M8kgGUlUA9Ft ew3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=u4GmOx2q5gJKD6SYU/1vAHoiNYQRo9PSyRAuDnoBM64=; b=AQJUYUEQcVQMB3pr72K0hw7s74S+5vJiZ909tEpMarBHXZwMeTpYFYPPADlso30TIz vMf/kupgykpvJH9hhva2sNitIbjsdFrnI5GaVEFzMBZNsRmONMfysvcSRAJ1WSX0PgbC uQt0/u/AH0DJeecl/HFsihtyACK8eIVdN+vd/U1pC5WvsN6umKkD97tFiaKjC6CmWqC8 HE9sgZpnS3x+WDCLBw3KQ00JLsEMP6bDHljBP6t5TpJJK5lb6J+e3JdxXXm67KA6vqF1 nvENJyDuMnMJk+zMghPyO2I+BO5srJJPMAuUQvXi0RcGknh8xPEOGkIlMMAtrzlvztQl 09ng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BzPLwuGo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o17-20020a170902d4d100b0018010c3d7e3si541653plg.404.2022.11.24.00.53.11; Thu, 24 Nov 2022 00:53:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BzPLwuGo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230008AbiKXIh6 (ORCPT + 88 others); Thu, 24 Nov 2022 03:37:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229541AbiKXIhb (ORCPT ); Thu, 24 Nov 2022 03:37:31 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7ABB8EC084 for ; Thu, 24 Nov 2022 00:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669278988; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=u4GmOx2q5gJKD6SYU/1vAHoiNYQRo9PSyRAuDnoBM64=; b=BzPLwuGon6bPexchG+58y7GY4+/hitHHWvORjJtLGbEe1URrz3P+VqMUlxPrPrEirW4VCq nzBWO3aAiGPjVzh7A+7IjKXXAjGUp5O+GNtr1zwNC/938fXtkwNXWDUkFitDgqVXODMiuP 7QHYlbF0cPHD4TZDYwochpmRkbwkPD8= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-367-1f4IjRiaONGImp1dR8pGFA-1; Thu, 24 Nov 2022 03:36:27 -0500 X-MC-Unique: 1f4IjRiaONGImp1dR8pGFA-1 Received: by mail-ej1-f72.google.com with SMTP id oz34-20020a1709077da200b007adc8d68e90so780340ejc.11 for ; Thu, 24 Nov 2022 00:36:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=u4GmOx2q5gJKD6SYU/1vAHoiNYQRo9PSyRAuDnoBM64=; b=saUzi0us86wMfP7n+ovCXEpVU5NxCKQRf0FY8WhYK9fh5WsyI7IEP8bgNT+BA3RzLI h1P4S1RQ7QftHmZRkR1gVhFEVLj/yG+Pe1wXSiI3M8Zk1VMjk6yvvQnrUt1Y/7cIYPMu V4AZKN44MbScL+4NJtJsawht+4VSwE9pbc2aBCRRsLGbwEDJruFLjKC78E15lwm/3jZD ATw/L+HW0Jl6xo/sHqakT3Jo+WyEQAgVy/rEnIkJ6DWkUUvu7C+3n1balxB8FTB1xoag ZPt9RTDZiJcK/ypMUsdi5uUKR4AesDwLKDcv7YBD8QsKywZ4twG/WB7LX4GTwBdmyiuQ h+Ag== X-Gm-Message-State: ANoB5pmZyQc9xeFOS5KVSUiWI/+HHP2OW7GZsMYDxBfLZeiPt/YQejCq jeEMCkPkCYc1AK8JO/QMzvt8j41hL/xz6puCL/Elqdl1OMXaoJH5IzQhiAkS5XpsfIqy0mxOLMa L3vVJTACcBDEgPkqjEUDdk4R2 X-Received: by 2002:a17:906:f281:b0:7ae:3b9e:1d8a with SMTP id gu1-20020a170906f28100b007ae3b9e1d8amr25550224ejb.581.1669278986165; Thu, 24 Nov 2022 00:36:26 -0800 (PST) X-Received: by 2002:a17:906:f281:b0:7ae:3b9e:1d8a with SMTP id gu1-20020a170906f28100b007ae3b9e1d8amr25550213ejb.581.1669278985941; Thu, 24 Nov 2022 00:36:25 -0800 (PST) Received: from ovpn-192-146.brq.redhat.com (nat-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id z21-20020aa7cf95000000b004614fd33789sm254331edx.18.2022.11.24.00.36.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Nov 2022 00:36:25 -0800 (PST) From: Vitaly Kuznetsov To: Vipin Sharma Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, seanjc@google.com, pbonzini@redhat.com, dmatlack@google.com Subject: Re: [PATCH v2 2/6] KVM: x86: hyper-v: Add extended hypercall support in Hyper-v In-Reply-To: References: <20221121234026.3037083-1-vipinsh@google.com> <20221121234026.3037083-3-vipinsh@google.com> <87bkozosvh.fsf@ovpn-194-185.brq.redhat.com> Date: Thu, 24 Nov 2022 09:36:24 +0100 Message-ID: <87wn7koik7.fsf@ovpn-192-146.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Vipin Sharma writes: > On Tue, Nov 22, 2022 at 8:29 AM Vitaly Kuznetsov wrote: >> >> Vipin Sharma writes: >> >> > +/* >> > + * The TLFS carves out 64 possible extended hypercalls, numbered sequentially >> > + * after the base capabilities extended hypercall. >> > + */ >> > +#define HV_EXT_CALL_MAX (HV_EXT_CALL_QUERY_CAPABILITIES + 64) >> > + >> >> First, I thought there's an off-by-one here (and should be '63') but >> then I checked with TLFS and figured out that the limit comes from >> HvExtCallQueryCapabilities's response which doesn't include itself >> (0x8001) in the mask, this means it can encode >> >> 0x8002 == bit0 >> 0x8003 == bit1 >> .. >> 0x8041 == bit63 >> >> so indeed, the last one supported is 0x8041 == 0x8001 + 64 >> >> maybe it's worth extending the commont on where '64' comes from. >> > > Yeah, I will expand comments. > >> > static void stimer_mark_pending(struct kvm_vcpu_hv_stimer *stimer, >> > bool vcpu_kick); >> > >> > @@ -2411,6 +2417,9 @@ static bool hv_check_hypercall_access(struct kvm_vcpu_hv *hv_vcpu, u16 code) >> > case HVCALL_SEND_IPI: >> > return hv_vcpu->cpuid_cache.enlightenments_eax & >> > HV_X64_CLUSTER_IPI_RECOMMENDED; >> > + case HV_EXT_CALL_QUERY_CAPABILITIES ... HV_EXT_CALL_MAX: >> > + return hv_vcpu->cpuid_cache.features_ebx & >> > + HV_ENABLE_EXTENDED_HYPERCALLS; >> > default: >> > break; >> > } >> > @@ -2564,6 +2573,12 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu) >> > } >> > goto hypercall_userspace_exit; >> > } >> > + case HV_EXT_CALL_QUERY_CAPABILITIES ... HV_EXT_CALL_MAX: >> > + if (unlikely(hc.fast)) { >> > + ret = HV_STATUS_INVALID_PARAMETER; >> >> I wasn't able to find any statement in TLFS stating whether extended >> hypercalls can be 'fast', I can imagine e.g. MemoryHeatHintAsync using >> it. Unfortunatelly, our userspace exit will have to be modified to >> handle such stuff. This can stay for the time being I guess.. >> > > I agree TLFS doesn't state anything about "fast" extended hypercall > but nothing stops in future for some call to be "fast". I think this > condition should also be handled by userspace as it is handling > everything else. > > I will remove it in the next version of the patch. I don't see any > value in verification here. The problem is that we don't currently pass 'fast' flag to userspace, let alone XMM registers. This means that it won't be able to handle fast hypercalls anyway, I guess it's better to keep your check but add a comment saying that it's an implementation shortcoming and not a TLFS requirement. > >> > + break; >> > + } >> > + goto hypercall_userspace_exit; >> > default: >> > ret = HV_STATUS_INVALID_HYPERCALL_CODE; >> > break; >> > @@ -2722,6 +2737,7 @@ int kvm_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid, >> > >> > ent->ebx |= HV_POST_MESSAGES; >> > ent->ebx |= HV_SIGNAL_EVENTS; >> > + ent->ebx |= HV_ENABLE_EXTENDED_HYPERCALLS; >> > >> > ent->edx |= HV_X64_HYPERCALL_XMM_INPUT_AVAILABLE; >> > ent->edx |= HV_FEATURE_FREQUENCY_MSRS_AVAILABLE; >> >> Reviewed-by: Vitaly Kuznetsov >> >> -- >> Vitaly >> > -- Vitaly