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