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 CB359C4332F for ; Tue, 16 Nov 2021 13:23:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B0A7861B31 for ; Tue, 16 Nov 2021 13:23:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236713AbhKPN0i (ORCPT ); Tue, 16 Nov 2021 08:26:38 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:44528 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236705AbhKPN01 (ORCPT ); Tue, 16 Nov 2021 08:26:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637069010; 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=7QB9Djd7unSuWFppJ6ryGSoufF2SRnNHGOPyI0tESn4=; b=ZIstAnW0E0rBi5YPmzUSbyRKpnq0DuO6PR50Jh4JD3q9SQe/gbMGDETnNGnz20QqQ7PKKd 6kLe4ilGFg11hvIySMDKfQ88SS7dHDVNQTQcFU6i/jqtJpfB9fYTj10LmjIGH7yr0JoyvK vf7oU3SyUiZQX2B1YsEZQD29hSCh41c= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-579-FxIFk6D0MG2caOT_jDHOzQ-1; Tue, 16 Nov 2021 08:23:29 -0500 X-MC-Unique: FxIFk6D0MG2caOT_jDHOzQ-1 Received: by mail-wm1-f69.google.com with SMTP id 201-20020a1c04d2000000b003335bf8075fso6484614wme.0 for ; Tue, 16 Nov 2021 05:23:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=7QB9Djd7unSuWFppJ6ryGSoufF2SRnNHGOPyI0tESn4=; b=22Y9DnTPW+T+pecLLyDFUE7J9/eTZxYC/HDCDRX/N5VkFNbjfl9UQ2ksjWW6m+4HwW 4mdZsVl13JU2ieQNgSErAhWCRUfr/lk/IWS3QUQYKg26PPFkhgnsg0VggyyTVP6h+MIs 7I9ehR5DFeWX9lmupUDQOL6a7ULW3ovB8btCnuf5oPRJAbayfxxHoSShy8L7ZhL6aVKU AEO5URrVHDLV0OTAfnwFb2OowXiyQSbL4KIattMxGdrQ60gQ/yurKzaJbL/soCJYrC4x AiQcVHMqpDubl059q1QY9MZtMC0TPK5FTz746cp5EgYfNkJLb88QbwXZ3JFc7aYK++p7 WuaQ== X-Gm-Message-State: AOAM532Pk5KlhNkuJH7uW8x7u8CnqWdEHSeWig3zU4rEU8wAGYbelftf imJTudd4lGwXD5ZagH70eryd+Kb4PAUodjWF5BJETf+m737YT8H2I5XrxkwXRSCE4Yge7rwMUkf /vxF+v+NOtsAM2XyCsp8G4BzquI50yF0sez++vgq0WsoVNcK4JRhdw/0ROU7ColhPgC3+wiUHlN Ju X-Received: by 2002:adf:fd90:: with SMTP id d16mr9035263wrr.385.1637069007901; Tue, 16 Nov 2021 05:23:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJypb9wLmwBU+C8U60E20ALWxdPmsGCyP6NgX66fxkM73bNsY5mStZduwVGh4q0guawc8+jIEQ== X-Received: by 2002:adf:fd90:: with SMTP id d16mr9035209wrr.385.1637069007612; Tue, 16 Nov 2021 05:23:27 -0800 (PST) Received: from fedora (g-server-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id n7sm17311363wro.68.2021.11.16.05.23.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 05:23:27 -0800 (PST) From: Vitaly Kuznetsov To: Paolo Bonzini , Marc Zyngier Cc: kvm@vger.kernel.org, Sean Christopherson , Wanpeng Li , Jim Mattson , Eduardo Habkost , Andrew Jones , 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 Subject: Re: [PATCH 1/5] KVM: arm64: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS In-Reply-To: References: <20211111162746.100598-1-vkuznets@redhat.com> <20211111162746.100598-2-vkuznets@redhat.com> <875ysxg0s1.fsf@redhat.com> <87k0hd8obo.wl-maz@kernel.org> Date: Tue, 16 Nov 2021 14:23:25 +0100 Message-ID: <87y25onsj6.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Paolo Bonzini writes: > On 11/12/21 15:02, Marc Zyngier wrote: >>> I'd like KVM to be consistent across architectures and have the same >>> (similar) meaning for KVM_CAP_NR_VCPUS. >> Sure, but this is a pretty useless piece of information anyway. As >> Andrew pointed out, the information is available somewhere else, and >> all we need to do is to cap it to the number of supported vcpus, which >> is effectively a KVM limitation. >> >> Also, we are talking about representing the architecture to userspace. >> No amount of massaging is going to make an arm64 box look like an x86. > > Not sure what you mean? The API is about providing a piece of > information independent of the architecture, while catering for a ppc > weirdness. Yes it's mostly useless if you don't care about ppc, but > it's not about making arm64 look like x86 or ppc; it's about not having > to special case ppc in userspace. > > If anything, if KVM_CAP_NR_VCPUS returns the same for kvm and !kvm, then > *that* is making an arm64 box look like an x86. On ARM the max vCPUs > depends on VM's GIC configuration, so KVM_CAP_NR_VCPUS should take that > into account. (I'm about to send v2 as we have s390 sorted out.) So what do we decide about ARM? - Current approach (kvm->arch.max_vcpus/kvm_arm_default_max_vcpus() depending on 'if (kvm)') - that would be my preference. - Always kvm_arm_default_max_vcpus to make the output independent on 'if (kvm)'. - keep the status quo (drop the patch). Please advise) -- Vitaly 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 CA8E5C433EF for ; Tue, 16 Nov 2021 13:24:52 +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 8E99461B31 for ; Tue, 16 Nov 2021 13:24:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8E99461B31 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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0To6SlHJ1lnXHjubDRN344Uotnhu6kc1meXY6EEqvYM=; b=HCKKJ4NEpazkxJ 0xvrBkWW0+NpS16LifSYCkYVv9R2XWAYwUoGg0VxbgJdHigodW+QnlQzV5l+1DFXBFGnnDvQqlgLj c8ageJVG6y/2NagDUAmHD8jRFyBrMckehigYn4b39GRJdOiqKa1BWI+P++AGUXvwZkJVafoBF0wsp 9bxEoctphJUj9lqozv6X5PZbs8576TmhjXRV6qGuv5DYwBZslRdFE8HiHTGq7jBL+/zSQr/NLHrk2 xw7zQdq+fxVMj0/tmyUf5U10BM0mNLojzEgCBiMwuWbb9cju+vjNg8vAEfooSSWKvfwoUjyPqCqVn rrm6dNauYS8U56dDzPww==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mmyQx-001nSq-Cf; Tue, 16 Nov 2021 13:23:35 +0000 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mmyQt-001nSH-ER for linux-arm-kernel@lists.infradead.org; Tue, 16 Nov 2021 13:23:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637069010; 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=7QB9Djd7unSuWFppJ6ryGSoufF2SRnNHGOPyI0tESn4=; b=ZIstAnW0E0rBi5YPmzUSbyRKpnq0DuO6PR50Jh4JD3q9SQe/gbMGDETnNGnz20QqQ7PKKd 6kLe4ilGFg11hvIySMDKfQ88SS7dHDVNQTQcFU6i/jqtJpfB9fYTj10LmjIGH7yr0JoyvK vf7oU3SyUiZQX2B1YsEZQD29hSCh41c= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-579-sFugCmWFNS-ro9R84ARH5w-1; Tue, 16 Nov 2021 08:23:29 -0500 X-MC-Unique: sFugCmWFNS-ro9R84ARH5w-1 Received: by mail-wm1-f72.google.com with SMTP id r6-20020a1c4406000000b0033119c22fdbso7359466wma.4 for ; Tue, 16 Nov 2021 05:23:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=7QB9Djd7unSuWFppJ6ryGSoufF2SRnNHGOPyI0tESn4=; b=InPJmr0n2aQz503q446b3hMuGA1Ra5xuS9Iao2afKncHvJbvFfAY+8isc5MXe+Prw1 cLxgZ9W1WW4x4uztx0kIZruYEasRAW4IRxpcio9C+voLyc4bNW7SV7nmZALmaa+pr7da Z+1qtvQXumK5NN4DeTBAzGdGBdu7f4y8S2hCYlyTu3mf0k70DA4zznbYlVhGFZiCrNuN S41dB3ha9Di+Krwy1dkRTt0fqe2Hlktxt5gQtItIfi9inNVvPSOIElVekQS+9eX6pwEl REMJmC5SgEH5akui9SxCL5C3xb29Hgv1hI+HbLAVv22clIFa8IWBx7rwu/mx7EUyn97d YxDw== X-Gm-Message-State: AOAM532MEigW5K2LmCKBIG2Juuq2c6loddUmZ7GAzKHr5XiWOGG7DoiA hgL3fRf8qCnYjrVMBviePjAl7TkTBbAkwOav9QDWcaax95pdn3BNWvFRnSoD4zdlGDNgt1MNkZI vT7yvSsmq52/QRxD5h0b9RbugHxcZXwySQ/c= X-Received: by 2002:adf:fd90:: with SMTP id d16mr9035258wrr.385.1637069007878; Tue, 16 Nov 2021 05:23:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJypb9wLmwBU+C8U60E20ALWxdPmsGCyP6NgX66fxkM73bNsY5mStZduwVGh4q0guawc8+jIEQ== X-Received: by 2002:adf:fd90:: with SMTP id d16mr9035209wrr.385.1637069007612; Tue, 16 Nov 2021 05:23:27 -0800 (PST) Received: from fedora (g-server-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id n7sm17311363wro.68.2021.11.16.05.23.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 05:23:27 -0800 (PST) From: Vitaly Kuznetsov To: Paolo Bonzini , Marc Zyngier Cc: kvm@vger.kernel.org, Sean Christopherson , Wanpeng Li , Jim Mattson , Eduardo Habkost , Andrew Jones , 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 Subject: Re: [PATCH 1/5] KVM: arm64: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS In-Reply-To: References: <20211111162746.100598-1-vkuznets@redhat.com> <20211111162746.100598-2-vkuznets@redhat.com> <875ysxg0s1.fsf@redhat.com> <87k0hd8obo.wl-maz@kernel.org> Date: Tue, 16 Nov 2021 14:23:25 +0100 Message-ID: <87y25onsj6.fsf@redhat.com> MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=vkuznets@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211116_052331_604102_EFF73675 X-CRM114-Status: GOOD ( 16.35 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Paolo Bonzini writes: > On 11/12/21 15:02, Marc Zyngier wrote: >>> I'd like KVM to be consistent across architectures and have the same >>> (similar) meaning for KVM_CAP_NR_VCPUS. >> Sure, but this is a pretty useless piece of information anyway. As >> Andrew pointed out, the information is available somewhere else, and >> all we need to do is to cap it to the number of supported vcpus, which >> is effectively a KVM limitation. >> >> Also, we are talking about representing the architecture to userspace. >> No amount of massaging is going to make an arm64 box look like an x86. > > Not sure what you mean? The API is about providing a piece of > information independent of the architecture, while catering for a ppc > weirdness. Yes it's mostly useless if you don't care about ppc, but > it's not about making arm64 look like x86 or ppc; it's about not having > to special case ppc in userspace. > > If anything, if KVM_CAP_NR_VCPUS returns the same for kvm and !kvm, then > *that* is making an arm64 box look like an x86. On ARM the max vCPUs > depends on VM's GIC configuration, so KVM_CAP_NR_VCPUS should take that > into account. (I'm about to send v2 as we have s390 sorted out.) So what do we decide about ARM? - Current approach (kvm->arch.max_vcpus/kvm_arm_default_max_vcpus() depending on 'if (kvm)') - that would be my preference. - Always kvm_arm_default_max_vcpus to make the output independent on 'if (kvm)'. - keep the status quo (drop the patch). Please advise) -- Vitaly _______________________________________________ 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: Vitaly Kuznetsov Date: Tue, 16 Nov 2021 13:23:25 +0000 Subject: Re: [PATCH 1/5] KVM: arm64: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS Message-Id: <87y25onsj6.fsf@redhat.com> List-Id: References: <20211111162746.100598-1-vkuznets@redhat.com> <20211111162746.100598-2-vkuznets@redhat.com> <875ysxg0s1.fsf@redhat.com> <87k0hd8obo.wl-maz@kernel.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Paolo Bonzini , Marc Zyngier Cc: kvm@vger.kernel.org, Sean Christopherson , Wanpeng Li , Jim Mattson , Eduardo Habkost , Andrew Jones , 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 Paolo Bonzini writes: > On 11/12/21 15:02, Marc Zyngier wrote: >>> I'd like KVM to be consistent across architectures and have the same >>> (similar) meaning for KVM_CAP_NR_VCPUS. >> Sure, but this is a pretty useless piece of information anyway. As >> Andrew pointed out, the information is available somewhere else, and >> all we need to do is to cap it to the number of supported vcpus, which >> is effectively a KVM limitation. >> >> Also, we are talking about representing the architecture to userspace. >> No amount of massaging is going to make an arm64 box look like an x86. > > Not sure what you mean? The API is about providing a piece of > information independent of the architecture, while catering for a ppc > weirdness. Yes it's mostly useless if you don't care about ppc, but > it's not about making arm64 look like x86 or ppc; it's about not having > to special case ppc in userspace. > > If anything, if KVM_CAP_NR_VCPUS returns the same for kvm and !kvm, then > *that* is making an arm64 box look like an x86. On ARM the max vCPUs > depends on VM's GIC configuration, so KVM_CAP_NR_VCPUS should take that > into account. (I'm about to send v2 as we have s390 sorted out.) So what do we decide about ARM? - Current approach (kvm->arch.max_vcpus/kvm_arm_default_max_vcpus() depending on 'if (kvm)') - that would be my preference. - Always kvm_arm_default_max_vcpus to make the output independent on 'if (kvm)'. - keep the status quo (drop the patch). Please advise) -- Vitaly