Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp5487203ybl; Tue, 27 Aug 2019 05:34:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqxSM3NqSD64C+BgpcxOmYTH9+cxoABeXhvdaWySIhCI2tcBGFExaE3HDQDadJyjVlMvhk1Q X-Received: by 2002:a17:90a:3266:: with SMTP id k93mr25513058pjb.46.1566909266943; Tue, 27 Aug 2019 05:34:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566909266; cv=none; d=google.com; s=arc-20160816; b=i7YsJm2sCWC0tHGZxQCntkQk7H2KD2gnpT8xxRTYbWoKkiVTR4CNj0+TXs5zghQRGd rHL+eiQcfLk1dX9XmbrzZL65WZgqbfVzJN+CZsUjCozDXnHgxPj+t/nAPcg85UwywD0f wiCambBMfUKs1kCoCRS7abeoJsmPFhi2UXUqBO7RWyElgLMfmqsgUagn9wG/ITBPhIhT EQWf/dOYF8CF18/9LHwOAswhTmcUewrAbP1tOwH3GxMlWdUQwBkEfhXIEf8EpQArdMYM +Qdp4/mhreW3Y08W1OCt2wzd3Q6QR3CFInBHNEqVtq6DI+YfJXBZpgB1+DyxfE5Q60pn JdfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=eLpuR9eRgxYeI49WIr/DhspGOopwmemU6oZ7y4W2wxE=; b=qwN9rjxP2dVZT6Dkgg9w7p/XqX2gFoEJmMKY1YdRirv+SHUnllrRbpzMpXuWXy3SPd hAEnHm+ez61bclUK3tnGs3gTf3pp0S9h/5h5dB6OAAkVna/9cxzd8O8rzfrRD/i5vEcB PW4HwqslA+T8kM3iOqYlV9z6uYC5SzLYW4HQB5kBkulzfERvjx1JJGEbt7/J3Bqccf3Y bW8l2O1M9wqXJbDGVPqcEFgHKf7k4N80b00qut4Hih1m+M4URoNbZGx1UZW5zGDdmtPE mx4emjW40CRq5dwzo+fvA1QCA3w9MsDf/zpeEAQu/XiDVeNcv23Zv/u6PyDMw8b1s/pK y1cw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NDT6L9KH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g13si12161189pgr.297.2019.08.27.05.34.10; Tue, 27 Aug 2019 05:34:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NDT6L9KH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728324AbfH0MdT (ORCPT + 99 others); Tue, 27 Aug 2019 08:33:19 -0400 Received: from mail-pg1-f196.google.com ([209.85.215.196]:36332 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726140AbfH0MdT (ORCPT ); Tue, 27 Aug 2019 08:33:19 -0400 Received: by mail-pg1-f196.google.com with SMTP id l21so12621181pgm.3; Tue, 27 Aug 2019 05:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eLpuR9eRgxYeI49WIr/DhspGOopwmemU6oZ7y4W2wxE=; b=NDT6L9KHNjR1GCoCxK1ZeypCroDAPTE9Xdbr9iwV5pnx2Iw3K2qiOkdU1O+7fEKxSG AHJ0Y2O77FZQ8BcfNtiTAXFJZGtNXJDfM2nYSSDXzfbOe6SYWDkaqmDw4/FMQNDR1MuB RUNGxcGSefzzagY2RfSHmRiVJpfQum72TScMtfnkvTWC19QpCao8tznI0seHahBJH3pE muxHfuh+rxQwYcfWDmxEnw36LJgHQU3yQYWIQlgkNbS1PVcBsQjIj0aO1zykAqKn4uDS AJHnOyT4ioAHBZSNWqzmy4MrOjx8Xog8B0FLqtfH5H0tTEnRs/xao3lAXKbPB6i8BUkA JP8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eLpuR9eRgxYeI49WIr/DhspGOopwmemU6oZ7y4W2wxE=; b=CiLPRIItLCQTpsiz3yJHqqmILDs3lhF46GTh1ldAb963QrwaX6Bsz2YRHPLuP5LjNN VhUx95c+HjEc9jMDmmu38UtoSqoFM9ikI2FB7EH4SovpXH+9QZakw0zwDE5KO+dRusoM 4TYbe0EptJhO2o+73hubdXK4FKGxNw45OHzVHMtNIf4nzn2fllB5GxVnZEPwRw2E5OlB gmsWCNWl4+Ax9rS4tl4zsd0qpGSoJmp/LoFPQEKfheH4hZfGtoxrNtsX3ap7/SHEB2br DlyJZlMKIysffJzpvgr7Bc5cBDTzZjQtQHRnUATBuA2qb7DzWluExN+KhdEaY9QI9Riz 2IBA== X-Gm-Message-State: APjAAAUBmaKIM9ld6Oiyqt4Xrs4xLbmnnT39YTA0w9f3mSBxbm+8i+MJ OAtXIh1MEAMec2Cxr8P8cENzKyZcV4YIYqwYcPI= X-Received: by 2002:aa7:8219:: with SMTP id k25mr11889026pfi.72.1566909198804; Tue, 27 Aug 2019 05:33:18 -0700 (PDT) MIME-Version: 1.0 References: <20190819131737.26942-1-Tianyu.Lan@microsoft.com> <87ftlnm7o8.fsf@vitty.brq.redhat.com> In-Reply-To: From: Tianyu Lan Date: Tue, 27 Aug 2019 20:33:08 +0800 Message-ID: Subject: Re: [PATCH V3 0/3] KVM/Hyper-V: Add Hyper-V direct tlb flush support To: Vitaly Kuznetsov Cc: Tianyu Lan , kvm , linux-doc@vger.kernel.org, linux-hyperv@vger.kernel.org, "linux-kernel@vger kernel org" , Paolo Bonzini , Radim Krcmar , corbet@lwn.net, KY Srinivasan , Haiyang Zhang , Stephen Hemminger , Sasha Levin , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "the arch/x86 maintainers" , michael.h.kelley@microsoft.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 27, 2019 at 8:17 PM Tianyu Lan wrote: > > On Tue, Aug 27, 2019 at 2:41 PM Vitaly Kuznetsov wrote: > > > > lantianyu1986@gmail.com writes: > > > > > From: Tianyu Lan > > > > > > This patchset is to add Hyper-V direct tlb support in KVM. Hyper-V > > > in L0 can delegate L1 hypervisor to handle tlb flush request from > > > L2 guest when direct tlb flush is enabled in L1. > > > > > > Patch 2 introduces new cap KVM_CAP_HYPERV_DIRECT_TLBFLUSH to enable > > > feature from user space. User space should enable this feature only > > > when Hyper-V hypervisor capability is exposed to guest and KVM profile > > > is hided. There is a parameter conflict between KVM and Hyper-V hypercall. > > > We hope L2 guest doesn't use KVM hypercall when the feature is > > > enabled. Detail please see comment of new API > > > "KVM_CAP_HYPERV_DIRECT_TLBFLUSH" > > > > I was thinking about this for awhile and I think I have a better > > proposal. Instead of adding this new capability let's enable direct TLB > > flush when KVM guest enables Hyper-V Hypercall page (writes to > > HV_X64_MSR_HYPERCALL) - this guarantees that the guest doesn't need KVM > > hypercalls as we can't handle both KVM-style and Hyper-V-style > > hypercalls simultaneously and kvm_emulate_hypercall() does: > > > > if (kvm_hv_hypercall_enabled(vcpu->kvm)) > > return kvm_hv_hypercall(vcpu); > > > > What do you think? > > > > (and instead of adding the capability we can add kvm.ko module parameter > > to enable direct tlb flush unconditionally, like > > 'hv_direct_tlbflush=-1/0/1' with '-1' being the default (autoselect > > based on Hyper-V hypercall enablement, '0' - permanently disabled, '1' - > > permanenetly enabled)). > > > > Hi Vitaly:: > Actually, I had such idea before. But user space should check > whether hv tlb flush > is exposed to VM before enabling direct tlb flush. If no, user space > should not direct > tlb flush for guest since Hyper-V will do more check for each > hypercall from nested > VM with enabling the feauter.. > Fix the line break.Sorry for noise. Actually, I had such idea before. But user space should check whether hv tlb flush is exposed to VM before enabling direct tlb flush. If no, user space should not direct tlb flush for guest since Hyper-V will do more check for each hypercall from nested VM with enabling the feauter.. --- Best regards Tianyu Lan