Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7870662rwb; Wed, 23 Nov 2022 11:55:50 -0800 (PST) X-Google-Smtp-Source: AA0mqf48+eKlJiv/Gowrhbjj6HvbxeV1Gfl092BeSFWMPv2sFCTfaoNNFLjnmn/4c4CQrHoru/Pi X-Received: by 2002:a17:906:5f87:b0:78d:8cf3:6ae with SMTP id a7-20020a1709065f8700b0078d8cf306aemr25276829eju.173.1669233350255; Wed, 23 Nov 2022 11:55:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669233350; cv=none; d=google.com; s=arc-20160816; b=z8nzOQIURe6HC99QD9DNVWMDHMilUNYJ89r/coNyJxTD/aYGlfSN36s7nnr36MQmgn uza5JJH/1utxri5eA5wOQ1V8VtbOvT7/9MAyxeLYaX2rTEqQgT5+1kxc+L2v28btWFXn gzsS8y98DbJdWUi4jnAaVIZZQhlN51/VP5MHTLBDNUXskm1Zm/PYGwbPwxC7PTRibgs4 vL72CSeI4eZcnFmqDreHLB7eDz+/IrO2nOuzsohdxuHRX5dcVo1b/cnhn4PieoNvPANL 8CZG946JvaK1vKKe/zxQjBf+zb5BG/QXv7F5ihGIjXA+tOkINsReEgXpui8p4QKqzKZK DfEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Hrl6+3qmvAqDeMuij9blfcXYnf1KVu5G00Q9l3GMlnI=; b=S8FfA13vFSwBFaYV274LXi1Oz7PgG8l/ZmJ3+ClvL1Eu85V80Ls8K0hiU4oswh3hYb 4mAJwmEIl1mpyMwJkxk/Q2H0c9VkSa8C3Hf2tBxk220GPD44X0+1xSjs007dl6w2ZtzI TACBPAuxuOM4egR78sbvL962qQwo4F2CgMea6S/6CBovqcF//ekg8IIiUIaJFzlHDJJO JDjgNrKZL4DjblQ/GdhaVJDXJnq6Jb/rp8UDcT7AydGUJllOTa+nM5q8ls/Xi/Q/uQnj h/OafQHSm1T3+G8CmjXVNF0uEClk5U0+Xd2VWMkCcXjBJjPFgl1cnHVBQp31UxH/CRjF ZyMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=SNovYVTa; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p10-20020a056402500a00b00461ace746adsi2368448eda.453.2022.11.23.11.55.25; Wed, 23 Nov 2022 11:55:50 -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=@google.com header.s=20210112 header.b=SNovYVTa; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236966AbiKWToY (ORCPT + 88 others); Wed, 23 Nov 2022 14:44:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233044AbiKWToW (ORCPT ); Wed, 23 Nov 2022 14:44:22 -0500 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DDAB09373D for ; Wed, 23 Nov 2022 11:44:20 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id cl5so31018973wrb.9 for ; Wed, 23 Nov 2022 11:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Hrl6+3qmvAqDeMuij9blfcXYnf1KVu5G00Q9l3GMlnI=; b=SNovYVTaZmO0i+VnP2+4GFFrm8M+cqdooCqNRT7svES0he9+w5RVtLotpNrcU7982X LrLz6V60QxdPoJHrUcQq5Yi/016rZZw+hFIDQ5N78JYzo6sUd59t7JCOfz1yqRFq8K+x XzuPHmZG+Vys29d4fZgydGrf9sGytKRWFckJO1JhzSL2NN1aFyD2s52suWj7EQAHmAas bGiMLZnScoritgF3Tca3OVmNqoZNGFfExjRnblQeGzblWkyHgqrrai3hzq34LsLxSuDp krz1xGxUwxCK4A+OUfInMuu55uUEW/9uDqdF9nCody/6Y+zwVMMlEPlPA04I5dkSY2j9 S+Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Hrl6+3qmvAqDeMuij9blfcXYnf1KVu5G00Q9l3GMlnI=; b=kJS2XTquIUJxHc0b1xLA3pXljgy21EHnEyW/Psdq9HzIWHHPChQeguHSxCJHYKPIoS SF3dXaf8KXVrKRfvoiudYiDZEpNkuy1c8mQg1chxRr57UQPF9QvKAkQhWxLN9jIGncGE MMdgM1EAMjDTwKmW/HXm1WRoOc81YcjbHZbXhOY0HiU7vm3rac7H8Ny8Dvsx+aNLCPEu n4js7udWTxB76p7NLqRy3kjr3yOAS8vQe39TbtDEp8zbv3Dt88xRsrRHl06KqUzia31i Lgiv8SHK68PuK63grkdz+InGtzb2xSsf9nmFGgLhJAOPPW0C6j7JTFxx3qJfMsW8PjlH TXkA== X-Gm-Message-State: ANoB5pkPfALHboOEI/IpdtuvpG3Ioax/WeT7xXRRFGeTVWv8J3Is7Wam bfaSYxw0BMZ8Y+99VsUzYBj/IX4eXpCKeJAhpYM2Vw== X-Received: by 2002:a05:6000:1192:b0:241:e7a6:9135 with SMTP id g18-20020a056000119200b00241e7a69135mr4550464wrx.641.1669232659216; Wed, 23 Nov 2022 11:44:19 -0800 (PST) MIME-Version: 1.0 References: <20221121234026.3037083-1-vipinsh@google.com> <20221121234026.3037083-3-vipinsh@google.com> <87bkozosvh.fsf@ovpn-194-185.brq.redhat.com> In-Reply-To: <87bkozosvh.fsf@ovpn-194-185.brq.redhat.com> From: Vipin Sharma Date: Wed, 23 Nov 2022 11:43:43 -0800 Message-ID: Subject: Re: [PATCH v2 2/6] KVM: x86: hyper-v: Add extended hypercall support in Hyper-v To: Vitaly Kuznetsov Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, seanjc@google.com, pbonzini@redhat.com, dmatlack@google.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 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. > > + 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 >