From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 217CFC433F5 for ; Fri, 12 Nov 2021 10:52:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0736760E98 for ; Fri, 12 Nov 2021 10:52:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234656AbhKLKzB (ORCPT ); Fri, 12 Nov 2021 05:55:01 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:46970 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233619AbhKLKy7 (ORCPT ); Fri, 12 Nov 2021 05:54:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1636714329; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lCPS80YSTbxrvBdmWutyocGvup+ukBCT7aUf6G8oGDE=; b=gV5V1YEMGlIJBFUDTsDLbCjWlXPdlTNPSMZkGPGA42y6LPvFWMb0qQXbVgXatyNjsieTo+ qHM+MV5nExBrQkbEirhJUIcj88vEqo2GRfkX4qmfXO1EN4oDs0Q6Sc0tsZAxBbUsmIBvQu aWYSH+SoOTz4rzdfydEj4JFnqjIvpmY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-363-iz5tOEPiOiu7gqOK80vfJg-1; Fri, 12 Nov 2021 05:52:06 -0500 X-MC-Unique: iz5tOEPiOiu7gqOK80vfJg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 74C8015721; Fri, 12 Nov 2021 10:52:03 +0000 (UTC) Received: from [10.39.193.118] (unknown [10.39.193.118]) by smtp.corp.redhat.com (Postfix) with ESMTP id CA02E19D9D; Fri, 12 Nov 2021 10:51:55 +0000 (UTC) Message-ID: Date: Fri, 12 Nov 2021 11:51:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH 1/5] KVM: arm64: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS Content-Language: en-US To: Andrew Jones , Vitaly Kuznetsov Cc: Marc Zyngier , kvm@vger.kernel.org, Sean Christopherson , Wanpeng Li , Jim Mattson , Eduardo Habkost , Huacai Chen , Aleksandar Markovic , Anup Patel , Paul Mackerras , Michael Ellerman , kvm-ppc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-kernel@vger.kernel.org References: <20211111162746.100598-1-vkuznets@redhat.com> <20211111162746.100598-2-vkuznets@redhat.com> <875ysxg0s1.fsf@redhat.com> <20211112103851.pmb35qf5bvcukjmg@gator.home> From: Paolo Bonzini In-Reply-To: <20211112103851.pmb35qf5bvcukjmg@gator.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/12/21 11:38, Andrew Jones wrote: >> >> I'd like KVM to be consistent across architectures and have the same >> (similar) meaning for KVM_CAP_NR_VCPUS. > KVM_CAP_NR_VCPUS seems pretty useless if we just want to tell userspace > the same thing it can get with _SC_NPROCESSORS_ONLN. In fact, if userspace > knows something we don't about the future onlining of some pcpus, then > maybe userspace would prefer to check _SC_NPROCESSORS_CONF. It's the same for most architectures, but for example PPC has to take into account the handling of threads, which can exist while the VMs run but not in the host. So KVM_CAP_NR_VCPUS on PPC is _SC_NPROCESSORS_CONF times the number of threads per core. If you don't count PPC (not sure about s390), it _is_ pretty useless indeed. Paolo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70067C433F5 for ; Fri, 12 Nov 2021 10:53:37 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3419160EFD for ; Fri, 12 Nov 2021 10:53:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3419160EFD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4Kg8cQoBapwXjMBVXi3THtZ+vctivqVm3TXNauotf7s=; b=3UW7dUqZlPxUAc 2cWO/lo/wrslF8Psbo875tXlbIAILq+uqqKAcsZBPX7A5n6McmxeYSOBZ9t88WLnnlMFVl2tS/9Wu Y/Ow1I5W3fmBhcKT19CLKiLn7tHYTg4Pw7LsPflTrig25+FBWVxSYnDgxvPxlkorNJsW8L8OiyEMq oHGOYSN/C8zyuDJbqG70xkknVV1Tiyn+51eBaCNgOG0JRwhtnAyPBKEEpI2ot4nKCW4WIs2GVHY7b aeTu7w3/e2zB2l/eAXoqm7OSt9PHNArCH5uQqlstgcCi0TZ2gg1PlC7c7jYyAcjFymfR6/G7wVVcq BLvLAEVOiFULsHJPk57w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mlUAI-009zFa-Fv; Fri, 12 Nov 2021 10:52:14 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mlUAE-009zE1-Aw for linux-arm-kernel@lists.infradead.org; Fri, 12 Nov 2021 10:52:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1636714329; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lCPS80YSTbxrvBdmWutyocGvup+ukBCT7aUf6G8oGDE=; b=gV5V1YEMGlIJBFUDTsDLbCjWlXPdlTNPSMZkGPGA42y6LPvFWMb0qQXbVgXatyNjsieTo+ qHM+MV5nExBrQkbEirhJUIcj88vEqo2GRfkX4qmfXO1EN4oDs0Q6Sc0tsZAxBbUsmIBvQu aWYSH+SoOTz4rzdfydEj4JFnqjIvpmY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-363-iz5tOEPiOiu7gqOK80vfJg-1; Fri, 12 Nov 2021 05:52:06 -0500 X-MC-Unique: iz5tOEPiOiu7gqOK80vfJg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 74C8015721; Fri, 12 Nov 2021 10:52:03 +0000 (UTC) Received: from [10.39.193.118] (unknown [10.39.193.118]) by smtp.corp.redhat.com (Postfix) with ESMTP id CA02E19D9D; Fri, 12 Nov 2021 10:51:55 +0000 (UTC) Message-ID: Date: Fri, 12 Nov 2021 11:51:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH 1/5] KVM: arm64: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS Content-Language: en-US To: Andrew Jones , Vitaly Kuznetsov Cc: Marc Zyngier , kvm@vger.kernel.org, Sean Christopherson , Wanpeng Li , Jim Mattson , Eduardo Habkost , Huacai Chen , Aleksandar Markovic , Anup Patel , Paul Mackerras , Michael Ellerman , kvm-ppc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-kernel@vger.kernel.org References: <20211111162746.100598-1-vkuznets@redhat.com> <20211111162746.100598-2-vkuznets@redhat.com> <875ysxg0s1.fsf@redhat.com> <20211112103851.pmb35qf5bvcukjmg@gator.home> From: Paolo Bonzini In-Reply-To: <20211112103851.pmb35qf5bvcukjmg@gator.home> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211112_025210_490558_663F7302 X-CRM114-Status: GOOD ( 13.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 11/12/21 11:38, Andrew Jones wrote: >> >> I'd like KVM to be consistent across architectures and have the same >> (similar) meaning for KVM_CAP_NR_VCPUS. > KVM_CAP_NR_VCPUS seems pretty useless if we just want to tell userspace > the same thing it can get with _SC_NPROCESSORS_ONLN. In fact, if userspace > knows something we don't about the future onlining of some pcpus, then > maybe userspace would prefer to check _SC_NPROCESSORS_CONF. It's the same for most architectures, but for example PPC has to take into account the handling of threads, which can exist while the VMs run but not in the host. So KVM_CAP_NR_VCPUS on PPC is _SC_NPROCESSORS_CONF times the number of threads per core. If you don't count PPC (not sure about s390), it _is_ pretty useless indeed. Paolo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Date: Fri, 12 Nov 2021 10:51:54 +0000 Subject: Re: [PATCH 1/5] KVM: arm64: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS Message-Id: List-Id: References: <20211111162746.100598-1-vkuznets@redhat.com> <20211111162746.100598-2-vkuznets@redhat.com> <875ysxg0s1.fsf@redhat.com> <20211112103851.pmb35qf5bvcukjmg@gator.home> In-Reply-To: <20211112103851.pmb35qf5bvcukjmg@gator.home> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Andrew Jones , Vitaly Kuznetsov Cc: Marc Zyngier , kvm@vger.kernel.org, Sean Christopherson , Wanpeng Li , Jim Mattson , Eduardo Habkost , Huacai Chen , Aleksandar Markovic , Anup Patel , Paul Mackerras , Michael Ellerman , kvm-ppc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-kernel@vger.kernel.org On 11/12/21 11:38, Andrew Jones wrote: >> >> I'd like KVM to be consistent across architectures and have the same >> (similar) meaning for KVM_CAP_NR_VCPUS. > KVM_CAP_NR_VCPUS seems pretty useless if we just want to tell userspace > the same thing it can get with _SC_NPROCESSORS_ONLN. In fact, if userspace > knows something we don't about the future onlining of some pcpus, then > maybe userspace would prefer to check _SC_NPROCESSORS_CONF. It's the same for most architectures, but for example PPC has to take into account the handling of threads, which can exist while the VMs run but not in the host. So KVM_CAP_NR_VCPUS on PPC is _SC_NPROCESSORS_CONF times the number of threads per core. If you don't count PPC (not sure about s390), it _is_ pretty useless indeed. Paolo