Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2844070pxb; Tue, 13 Apr 2021 11:30:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyi9cBRtZyP3q+P2raMD0xnp4cSvTCTbfHVsZVml68cUC11u7zEpzgvxJKX40kxm5mKl62Z X-Received: by 2002:a17:906:c79a:: with SMTP id cw26mr13867800ejb.220.1618338649110; Tue, 13 Apr 2021 11:30:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618338649; cv=none; d=google.com; s=arc-20160816; b=oiDDPH/TJD73wuq+/kI+SUmKntKEnMx99V9JAvrIKhKZz4LpsObqCld042MifISdq6 hOJ3K7b1jlBu40Heimy46/KGwx1EGRE1oAzNQCpc6VjxmHkNtkFl8oxhOciBTzazraZu GJsCczrOu+VILMerk08Dz2iNIWc++zClIA/p5z6w4Vql+/3Do/bu5LvmvsBRfC/HnMyV sfBlVvE9M7uK0masrO0jVi26irhtt5wIqt5lX2yILVIfmfgcNarZbaH5xvAFWfpUZ92e TA0BFb8EYV4vbA2Y+/oQ3p1nFTbAogXvh3srpC8KPmbAwYzJbyAgeC2HCj2G8TH1xgZk iyzw== 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=l1tsPKvk9cyMrjFqY00fCJRrMWcEEfacpS/IxrFGbrA=; b=L0/OhT4ryl2snsto9R8gQItgbR6diBG3/94CTkMZcEHyKFLVlE4XQGmPIln+CtVQ2R 0CoQdv7/bBpg7Ku1EudhEJp4PPXoRJe5sNRAEncY2uiozTEWkZCfTsktaBTC2aSxg3Kg HHAWGMeL9Rn2isS7shdXzXImWLsTMbFx0noU6dofYU4UAhR0H58vno2RVNQ3D+ILl5OF OTLl0Gu6dFpJGlw7UwWHV7zoYsCieXCesaFDvYxwRrdbnko8wYKMsh8Jmc0s+njYyQbx M4ehWMnZIcCi5usPZPNqRsj5ObodSWVhJh39SubBfrb66YNRQXasnlFycG3YhQZVT8Ft viow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gxWo2636; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w5si10463254ejz.607.2021.04.13.11.30.26; Tue, 13 Apr 2021 11:30:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gxWo2636; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1346273AbhDMOKP (ORCPT + 99 others); Tue, 13 Apr 2021 10:10:15 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:24591 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346262AbhDMOKO (ORCPT ); Tue, 13 Apr 2021 10:10:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618322994; 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=l1tsPKvk9cyMrjFqY00fCJRrMWcEEfacpS/IxrFGbrA=; b=gxWo263604U4Mq6RZDOjmANzPMIgUVxp1tK97XuYR54+EQq8w1LTdlfyUaEniE1DV84YeH BqC4mJS5fPWinOHvPOjrFKPS+bhrv7wfsdG4XsoEY2690Ufgu+/nLdNdm8bTgHvHtVWA4t r74YOPj0EarlF0wBUz0UB9ZY/oYFMJw= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-92-ohlGeBegPemKTzXdzILS8Q-1; Tue, 13 Apr 2021 10:09:51 -0400 X-MC-Unique: ohlGeBegPemKTzXdzILS8Q-1 Received: by mail-ej1-f69.google.com with SMTP id d6so5080834ejd.15 for ; Tue, 13 Apr 2021 07:09:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=l1tsPKvk9cyMrjFqY00fCJRrMWcEEfacpS/IxrFGbrA=; b=Gvng/h/CxTBph5m1aTK3Q08GrxY4qUmSGwZpAH0YgD9f3Li5AxhEEfownyT9519fWL /xaQYk5LToiTnX+vu6gPJLH0nyTGBTIBcpNWmzJxd1toHW8Gijycc810zU6ZiWsxFRD2 ly1WaA175o1fbS78jfBGhdxNETwB1WT3eCHGxKllqRZ2+U5aPSnIazzcP0cD4b3ClnhM 9fPz4tcIZqD/6P1hxFIaeVt2dV3BhhY/ycUYEnTOZgkXjJ/nJo9ALM31v49i7WTpvRIC SCR2wKfqlwghQ9421TIOHeHstiX5acfx39m90YKyz6dVdYap/64GlixLgtbFoU6Ocgw2 yeMg== X-Gm-Message-State: AOAM533dNPXT2aejowdnaWIcF9Tckibo5puZCauFWLwAseSVZ6nYcU4h 4wbVlr9rkmGGEveG2wlA67yJ9g85qnqBmIPHUEom6AgSCdoCPEHZL0GdrE1rFa9IBnN8LNrUUv/ zB4pjY/6qoPWWxMMy1QTJnxUl X-Received: by 2002:a17:906:cb88:: with SMTP id mf8mr13912495ejb.541.1618322990370; Tue, 13 Apr 2021 07:09:50 -0700 (PDT) X-Received: by 2002:a17:906:cb88:: with SMTP id mf8mr13912466ejb.541.1618322990130; Tue, 13 Apr 2021 07:09:50 -0700 (PDT) Received: from vitty.brq.redhat.com (g-server-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id c2sm9618972edr.57.2021.04.13.07.09.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Apr 2021 07:09:49 -0700 (PDT) From: Vitaly Kuznetsov To: Siddharth Chandrasekaran Cc: Alexander Graf , Evgeny Iakovlev , Liran Alon , Ioannis Aslanidis , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Wei Liu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Paolo Bonzini , Sean Christopherson , Wanpeng Li , Jim Mattson , Joerg Roedel Subject: Re: [PATCH v2 3/4] KVM: x86: kvm_hv_flush_tlb use inputs from XMM registers In-Reply-To: References: Date: Tue, 13 Apr 2021 16:09:48 +0200 Message-ID: <87sg3u5l8z.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Siddharth Chandrasekaran writes: > Hyper-V supports the use of XMM registers to perform fast hypercalls. > This allows guests to take advantage of the improved performance of the > fast hypercall interface even though a hypercall may require more than > (the current maximum of) two input registers. > > The XMM fast hypercall interface uses six additional XMM registers (XMM0 > to XMM5) to allow the guest to pass an input parameter block of up to > 112 bytes. Hyper-V can also return data back to the guest in the > remaining XMM registers that are not used by the current hypercall. > > Add framework to read/write to XMM registers in kvm_hv_hypercall() and > use the additional hypercall inputs from XMM registers in > kvm_hv_flush_tlb() when possible. > > Cc: Alexander Graf > Co-developed-by: Evgeny Iakovlev > Signed-off-by: Evgeny Iakovlev > Signed-off-by: Siddharth Chandrasekaran > --- > arch/x86/kvm/hyperv.c | 109 ++++++++++++++++++++++++++++++++++-------- > 1 file changed, 90 insertions(+), 19 deletions(-) > > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c > index 8f6babd1ea0d..1f9959aba70d 100644 > --- a/arch/x86/kvm/hyperv.c > +++ b/arch/x86/kvm/hyperv.c > @@ -36,6 +36,7 @@ > > #include "trace.h" > #include "irq.h" > +#include "fpu.h" > > /* "Hv#1" signature */ > #define HYPERV_CPUID_SIGNATURE_EAX 0x31237648 > @@ -1623,6 +1624,8 @@ static __always_inline unsigned long *sparse_set_to_vcpu_mask( > return vcpu_bitmap; > } > > +#define KVM_HV_HYPERCALL_MAX_XMM_REGISTERS 6 Nitpick: this is not KVM-specific so could probably go to arch/x86/include/asm/hyperv-tlfs.h > + > struct kvm_hv_hcall { > u64 param; > u64 ingpa; > @@ -1632,10 +1635,14 @@ struct kvm_hv_hcall { > u16 rep_idx; > bool fast; > bool rep; > + sse128_t xmm[KVM_HV_HYPERCALL_MAX_XMM_REGISTERS]; > + bool xmm_dirty; > }; > > static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc, bool ex) > { > + int i, j; > + gpa_t gpa; > struct kvm *kvm = vcpu->kvm; > struct kvm_vcpu_hv *hv_vcpu = to_hv_vcpu(vcpu); > struct hv_tlb_flush_ex flush_ex; > @@ -1649,8 +1656,15 @@ static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc, bool > bool all_cpus; > > if (!ex) { > - if (unlikely(kvm_read_guest(kvm, hc->ingpa, &flush, sizeof(flush)))) > - return HV_STATUS_INVALID_HYPERCALL_INPUT; > + if (hc->fast) { > + flush.address_space = hc->ingpa; > + flush.flags = hc->outgpa; > + flush.processor_mask = sse128_lo(hc->xmm[0]); > + } else { > + if (unlikely(kvm_read_guest(kvm, hc->ingpa, > + &flush, sizeof(flush)))) > + return HV_STATUS_INVALID_HYPERCALL_INPUT; > + } > > trace_kvm_hv_flush_tlb(flush.processor_mask, > flush.address_space, flush.flags); > @@ -1668,9 +1682,16 @@ static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc, bool > all_cpus = (flush.flags & HV_FLUSH_ALL_PROCESSORS) || > flush.processor_mask == 0; > } else { > - if (unlikely(kvm_read_guest(kvm, hc->ingpa, &flush_ex, > - sizeof(flush_ex)))) > - return HV_STATUS_INVALID_HYPERCALL_INPUT; > + if (hc->fast) { > + flush_ex.address_space = hc->ingpa; > + flush_ex.flags = hc->outgpa; > + memcpy(&flush_ex.hv_vp_set, > + &hc->xmm[0], sizeof(hc->xmm[0])); > + } else { > + if (unlikely(kvm_read_guest(kvm, hc->ingpa, &flush_ex, > + sizeof(flush_ex)))) > + return HV_STATUS_INVALID_HYPERCALL_INPUT; > + } > > trace_kvm_hv_flush_tlb_ex(flush_ex.hv_vp_set.valid_bank_mask, > flush_ex.hv_vp_set.format, > @@ -1681,20 +1702,29 @@ static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *hc, bool > all_cpus = flush_ex.hv_vp_set.format != > HV_GENERIC_SET_SPARSE_4K; > > - sparse_banks_len = > - bitmap_weight((unsigned long *)&valid_bank_mask, 64) * > - sizeof(sparse_banks[0]); > + sparse_banks_len = bitmap_weight((unsigned long *)&valid_bank_mask, 64); > > if (!sparse_banks_len && !all_cpus) > goto ret_success; > > - if (!all_cpus && > - kvm_read_guest(kvm, > - hc->ingpa + offsetof(struct hv_tlb_flush_ex, > - hv_vp_set.bank_contents), > - sparse_banks, > - sparse_banks_len)) > - return HV_STATUS_INVALID_HYPERCALL_INPUT; > + if (!all_cpus) { > + if (hc->fast) { > + if (sparse_banks_len > KVM_HV_HYPERCALL_MAX_XMM_REGISTERS - 1) > + return HV_STATUS_INVALID_HYPERCALL_INPUT; > + for (i = 0, j = 1; i < sparse_banks_len; i += 2, j++) { Nitpick: you don't really need 'j' here as 'j == i/2 + 1', right? > + sparse_banks[i + 0] = sse128_lo(hc->xmm[j]); Using ' + 0' for identation is ... unusual :-) I'm not opposed to it here though. > + sparse_banks[i + 1] = sse128_hi(hc->xmm[j]); > + } > + } else { > + gpa = hc->ingpa; > + gpa += offsetof(struct hv_tlb_flush_ex, > + hv_vp_set.bank_contents); Nitpick: if splitting these into two lines is only done to fit into 80 chars then I'd the requirement is no more so we can be a bit wider. gpa = hc->ingpa + offsetof(...) > + if (unlikely(kvm_read_guest(kvm, gpa, sparse_banks, > + sparse_banks_len * > + sizeof(sparse_banks[0])))) > + return HV_STATUS_INVALID_HYPERCALL_INPUT; > + } > + } > } > > cpumask_clear(&hv_vcpu->tlb_flush); > @@ -1890,6 +1920,41 @@ static u16 kvm_hvcall_signal_event(struct kvm_vcpu *vcpu, struct kvm_hv_hcall *h > return HV_STATUS_SUCCESS; > } > > +static bool is_xmm_fast_hypercall(struct kvm_hv_hcall *hc) > +{ > + switch (hc->code) { > + case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST: > + case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE: > + case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX: > + case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX: > + return true; > + } > + > + return false; > +} > + > +static inline void kvm_hv_hypercall_read_xmm(struct kvm_hv_hcall *hc) > +{ > + int reg; > + > + kvm_fpu_get(); > + for (reg = 0; reg < KVM_HV_HYPERCALL_MAX_XMM_REGISTERS; reg++) > + _kvm_read_sse_reg(reg, &hc->xmm[reg]); > + kvm_fpu_put(); > + hc->xmm_dirty = false; > +} > + > +static inline void kvm_hv_hypercall_write_xmm(struct kvm_hv_hcall *hc) > +{ > + int reg; > + > + kvm_fpu_get(); > + for (reg = 0; reg < KVM_HV_HYPERCALL_MAX_XMM_REGISTERS; reg++) > + _kvm_write_sse_reg(reg, &hc->xmm[reg]); > + kvm_fpu_put(); > + hc->xmm_dirty = false; > +} > + > int kvm_hv_hypercall(struct kvm_vcpu *vcpu) > { > struct kvm_hv_hcall hc; > @@ -1926,6 +1991,9 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu) > hc.rep_idx = (hc.param >> HV_HYPERCALL_REP_START_OFFSET) & 0xfff; > hc.rep = !!(hc.rep_cnt || hc.rep_idx); > > + if (hc.fast && is_xmm_fast_hypercall(&hc)) > + kvm_hv_hypercall_read_xmm(&hc); > + > trace_kvm_hv_hypercall(hc.code, hc.fast, hc.rep_cnt, hc.rep_idx, > hc.ingpa, hc.outgpa); > > @@ -1961,28 +2029,28 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu) > kvm_hv_hypercall_complete_userspace; > return 0; > case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST: > - if (unlikely(hc.fast || !hc.rep_cnt || hc.rep_idx)) { > + if (unlikely(!hc.rep_cnt || hc.rep_idx)) { > ret = HV_STATUS_INVALID_HYPERCALL_INPUT; > break; > } > ret = kvm_hv_flush_tlb(vcpu, &hc, false); > break; > case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE: > - if (unlikely(hc.fast || hc.rep)) { > + if (unlikely(hc.rep)) { > ret = HV_STATUS_INVALID_HYPERCALL_INPUT; > break; > } > ret = kvm_hv_flush_tlb(vcpu, &hc, false); > break; > case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX: > - if (unlikely(hc.fast || !hc.rep_cnt || hc.rep_idx)) { > + if (unlikely(!hc.rep_cnt || hc.rep_idx)) { > ret = HV_STATUS_INVALID_HYPERCALL_INPUT; > break; > } > ret = kvm_hv_flush_tlb(vcpu, &hc, true); > break; > case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX: > - if (unlikely(hc.fast || hc.rep)) { > + if (unlikely(hc.rep)) { > ret = HV_STATUS_INVALID_HYPERCALL_INPUT; > break; > } > @@ -2035,6 +2103,9 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu) > break; > } > > + if (hc.xmm_dirty) > + kvm_hv_hypercall_write_xmm(&hc); > + Wei already mention that but as 'xmm_dirty' is not being used in this patch I'd suggest we move it out too. > return kvm_hv_hypercall_complete(vcpu, ret); > } -- Vitaly