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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EC1CC433ED for ; Wed, 19 May 2021 03:19:49 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 857D561007 for ; Wed, 19 May 2021 03:19:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 857D561007 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:54578 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ljCkN-0000o8-JD for qemu-devel@archiver.kernel.org; Tue, 18 May 2021 23:19:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55016) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ljCjE-0007QK-Pc; Tue, 18 May 2021 23:18:36 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:3429) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ljCjB-0005xx-V9; Tue, 18 May 2021 23:18:36 -0400 Received: from dggems702-chm.china.huawei.com (unknown [172.30.72.59]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4FlHzZ0N3szNywX; Wed, 19 May 2021 11:14:50 +0800 (CST) Received: from dggpemm500023.china.huawei.com (7.185.36.83) by dggems702-chm.china.huawei.com (10.3.19.179) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 19 May 2021 11:18:19 +0800 Received: from [10.174.187.128] (10.174.187.128) by dggpemm500023.china.huawei.com (7.185.36.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Wed, 19 May 2021 11:18:18 +0800 Subject: Re: [RFC PATCH v2 5/6] hw/arm/virt-acpi-build: Add PPTT table To: Salil Mehta , Andrew Jones References: <20210413080745.33004-1-wangyanan55@huawei.com> <20210413080745.33004-6-wangyanan55@huawei.com> <1551b7d6-e010-e5c7-47e1-c347ca78a1db@huawei.com> <20210518074221.umezsdedzyzmcbsk@gator.home> <80dca9f16c5b4bef9900f6cf76c99500@huawei.com> <20210518190539.fwsvl2ijb4jlzbyi@gator.home> From: "wangyanan (Y)" Message-ID: <224d54ac-0c03-afc4-4aec-ea3435aa68e7@huawei.com> Date: Wed, 19 May 2021 11:18:18 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.174.187.128] X-ClientProxiedBy: dggeme718-chm.china.huawei.com (10.1.199.114) To dggpemm500023.china.huawei.com (7.185.36.83) X-CFilter-Loop: Reflected Received-SPF: pass client-ip=45.249.212.191; envelope-from=wangyanan55@huawei.com; helo=szxga05-in.huawei.com X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , "linuxarm@openeuler.org" , "Michael S . Tsirkin" , "qemu-devel@nongnu.org" , Linuxarm , Shannon Zhao , Igor Mammedov , "qemu-arm@nongnu.org" , Alistair Francis , "Zengtao \(B\)" , yangyicong , yuzenghui , "Wanghaibin \(D\)" , zhukeqian , "lijiajie \(H\)" , David Gibson Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 2021/5/19 3:22, Salil Mehta wrote: >> From: Andrew Jones [mailto:drjones@redhat.com] >> Sent: Tuesday, May 18, 2021 8:06 PM >> To: Salil Mehta >> Cc: wangyanan (Y) ; Peter Maydell >> ; Michael S . Tsirkin ; Wanghaibin >> (D) ; qemu-devel@nongnu.org; Shannon Zhao >> ; qemu-arm@nongnu.org; Alistair Francis >> ; Zengtao (B) ; >> yangyicong ; yuzenghui ; Igor >> Mammedov ; zhukeqian ; lijiajie (H) >> ; David Gibson ; Linuxarm >> ; linuxarm@openeuler.org >> Subject: Re: [RFC PATCH v2 5/6] hw/arm/virt-acpi-build: Add PPTT table >> >> On Tue, May 18, 2021 at 06:34:08PM +0000, Salil Mehta wrote: >>> Those benefits, when vcpu pinning is used, are the same benefits >>>> as for the host, which already use PPTT tables to describe topology, even >>>> though hot plug isn't supported. >>> yes sure, you mean pinning vcpus according to the cpu topology for performance? >> Yup > Already Agreed :) > >>>> Now, if you're saying we should only generate tables for smp.cpus, not >>> Correct. This is what I thought we must be doing even now >>> >>>> smp.maxcpus, because hot plug isn't supported anyway, then I see your >>>> point. But, it'd be better to require smp.cpus == smp.maxcpus in our >>>> smp_parse function to do that, which we've never done before, so we may >>>> have trouble supporting existing command lines. >>> I am trying to recall, if the vcpu Hotplug is not supported then can they >>> ever be different? >>> >>> cpus = (threads * cores * sockets) >>> >>> static void smp_parse(MachineState *ms, QemuOpts *opts) >>> { >>> [...] >>> >>> if (sockets * cores * threads != ms->smp.max_cpus) { >>> warn_report("Invalid CPU topology deprecated: " >>> "sockets (%u) * cores (%u) * threads (%u) " >>> "!= maxcpus (%u)", >>> sockets, cores, threads, >>> ms->smp.max_cpus); >>> } >>> [...] >>> } >>> >>> Although, above check does not exit(1) and just warns on detecting invalid >>> CPU topology. Not sure why? >> Hmm, not sure what code you have there. I see this in >> hw/core/machine.c:smp_parse >> >> if (ms->smp.max_cpus < cpus) { >> error_report("maxcpus must be equal to or greater than smp"); >> exit(1); >> } >> >> if (sockets * cores * threads != ms->smp.max_cpus) { >> error_report("Invalid CPU topology: " >> "sockets (%u) * cores (%u) * threads (%u) " >> "!= maxcpus (%u)", >> sockets, cores, threads, >> ms->smp.max_cpus); >> exit(1); >> } >> >>> Well if you think there are subtleties to support above implementation and >>> we cannot do it now then sure it is your call. :) Hi Salil, Drew, >> The problem is that -smp 4,maxcpus=8 doesn't error out today, even though >> it doesn't do anything. OTOH, -smp 4,cores=2 doesn't error out either, but >> we're proposing that it should. Maybe we can start erroring out when >> cpus != maxcpus until hot plug is supported? > Agreed, both don't make any sense if hotplug is not supported and ideally should > fail with error. We should block any such topology configuration. In the ARM-specific function virt_smp_parse() (patch 9), there already have been some restrictions for the given -smp configuration. We now only allow: -smp N -smp maxcpus=M -smp N, maxcpus=M -smp N, sockets=X, cores=Y -smp N, sockets=X, cores=Y, threads=Z -smp maxcpus=M, sockets=X, cores=Y -smp maxcpus=M, sockets=X, cores=Y, threads=Z -smp N, maxcpus=M, sockets=X, cores=Y -smp N, maxcpus=M, sockets=X, cores=Y, threads=Z and disallow the other strange and rare formats that shouldn't be provided. It's reasonable to block the topology configuration which is not useful currently. I will add the requirement for "cpus==maxcpus" in this fuction if the possible conflict with existing command lines is not a big problem. Thanks, Yanan > > Thanks > Salil > .