Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4467501imm; Fri, 18 May 2018 05:43:15 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrmrAFbHGfwDLCzAXJieuPh9yW/kOnU/UIJdVJnSB8P8YldQIlJJdnaf4Q5Y5xSWt/EsQa7 X-Received: by 2002:a63:9541:: with SMTP id t1-v6mr5387682pgn.77.1526647395172; Fri, 18 May 2018 05:43:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526647395; cv=none; d=google.com; s=arc-20160816; b=q+FvGpcY4Eo/lXQ91VfrZwdxkxo5PeT6aOXBQ0YaWFmJi8A4NsvFI8tM5iQyZFHhr2 nCGIjItEluhfgTnDSr5KRQkgMKyVzmOM3RvmtCtKcQQtoaTqsnJbwU4Uia5lBY6Z6j53 +E5mY1mgEkYC14cBC7GnHFtB84uhFXvEOWct8h1uirDLe/O0WVXrddnekkWIvyvHIc9s 2aXSTplGAjVuRZk1SLjCq8GRZalE5WGm2LkQmY2F211HYMob6uRPv1vQPw2tR11/Jjhb CWF0XNrWfl+khvEfe91osR+QxggfRbZDEIeZO8Z9rzEW5zJ83lAk/rDfh0nVjHLBNC/A AsAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from :arc-authentication-results; bh=vGidVbnXoe0Xc975NLXBsqzJ/8lpkd7xa/1Cwp/tlQQ=; b=CzVZ5G01pFSpI/+xJVF/E6ZAVVvwOXBAYcZzOFXxi4u9jdJxDzAWQ26z6r7cEYXjAk lYn9qNz4rIlKzHPMpvmDv0dbCQiXRMBg5GDf+Io/0N8I2DyrAb7112rJJrWt4e6sogre F3rwwIuUye988VpzE7qaOIvgLkSe3L1rM6I1TnVgAec3nGRKjlPOm5ObZhbE5RG1TfO8 6hJGR+3Z1HtouiFwJRkkSJlg3CqVKLcja0CABXhQ1zHu2p3Z5jaykJ49f5NuVXjXsI8R tGAUnUo6jLs+a79ERyyz4ph8Cix5/VhzK1Z0jiS1LeKTYn2zcv+Oid1O8vDRuyVbjDwg 1q5g== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h1-v6si5830118pgn.430.2018.05.18.05.43.00; Fri, 18 May 2018 05:43:15 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751589AbeERMmj (ORCPT + 99 others); Fri, 18 May 2018 08:42:39 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:48616 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750841AbeERMmg (ORCPT ); Fri, 18 May 2018 08:42:36 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DCC4679D36; Fri, 18 May 2018 12:42:35 +0000 (UTC) Received: from vitty.brq.redhat.com.redhat.com (unknown [10.43.2.155]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 04C1510EE964; Fri, 18 May 2018 12:42:33 +0000 (UTC) From: Vitaly Kuznetsov To: Wanpeng Li Cc: kvm , "the arch\/x86 maintainers" , Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , Roman Kagan , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , "Michael Kelley \(EOSG\)" , Mohammed Gamal , Cathy Avery , LKML Subject: Re: [PATCH v4 0/8] KVM: x86: hyperv: PV TLB flush for Windows guests References: <20180516152131.30689-1-vkuznets@redhat.com> <87bmddgrex.fsf@vitty.brq.redhat.com> <8736ypgqie.fsf@vitty.brq.redhat.com> Date: Fri, 18 May 2018 14:42:32 +0200 In-Reply-To: (Wanpeng Li's message of "Fri, 18 May 2018 19:56:13 +0800") Message-ID: <87y3ghf83r.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 18 May 2018 12:42:35 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 18 May 2018 12:42:35 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'vkuznets@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Wanpeng Li writes: > 2018-05-18 19:19 GMT+08:00 Vitaly Kuznetsov : >> Vitaly Kuznetsov writes: >> >>> Wanpeng Li writes: >>> >>>> Hi Vitaly, >>>> 2018-05-16 23:21 GMT+08:00 Vitaly Kuznetsov : >>>>> Changes since v3 [Radim Krcmar]: >>>>> - PATCH2 fixing 'HV_GENERIC_SET_SPARCE_4K' typo added. >>>>> - PATCH5 introducing kvm_make_vcpus_request_mask() API added. >>>>> - Fix undefined behavior for hv->vp_index >= 64. >>>>> - Merge kvm_hv_flush_tlb() and kvm_hv_flush_tlb_ex() >>>>> - For -ex case preload all banks with a single kvm_read_guest(). >>>>> >>>>> Description: >>>>> >>>>> This is both a new feature and a bugfix. >>>>> >>>>> Bugfix description: >>>>> >>>>> It was found that Windows 2016 guests on KVM crash when they have > 64 >>>>> vCPUs, non-flat topology (>1 core/thread per socket; in case it has >64 >>>>> sockets Windows just ignores vCPUs above 64) and Hyper-V enlightenments >>>> >>>> We try the below command line, the Windows 2016 guest successfully to >>>> login and there are 80 vCPUs can be observed in the guest w/o the >>>> patchset, why you mentioned the crash and ignore? >>>> >>>> /usr/local/bin/qemu-system-x86_64 -machine pc-i440fx-rhel7.3.0 -m >>>> 8192 -smp 80,sockets=2,cores=40,threads=1 -device >>>> ide-drive,bus=ide.0,drive=test -drive >>>> id=test,if=none,file=/instanceimage/359b18ab-05bb-460d-9b53-89505bca68ed/359b18ab-05bb-460d-9b53-89505bca68ed_vda_1.qcow2 >>>> -net nic,model=virtio -net user -monitor stdio -usb -usbdevice tablet >>>> --enable-kvm --cpu host -vnc 0.0.0.0:2 >>> >>> Crash happens when you manifest yourself as Hyper-V, you can do this by >>> adding any 'hv-*' feature (e.g. try '-cpu host,hv_vpindex'). >> >> Oh, and the 'ignore' happens when you pass more than 64 sockets >> (somthing like "-smp 128,sockets=128,cores=1,threads=1") -- and this >> happens regardless of Hyper-V enlightenments. But I guess it's just >> because Windows doesn't support more than 64 sockets. > > Is there an option in the guest to avoid to check pvtlb support in hyperv? > You mean to tell Windows to not use PV TLB flush when it's available? I have no idea. My guess would be that it's left up to the hypervisor: if the feature is available Windows will use it. -- Vitaly