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,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 ADF48C433ED for ; Wed, 19 May 2021 13:51:44 +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 1981E6100C for ; Wed, 19 May 2021 13:51:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1981E6100C 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]:51824 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ljMbv-00062x-9W for qemu-devel@archiver.kernel.org; Wed, 19 May 2021 09:51:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40522) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ljMDi-0003qw-1I; Wed, 19 May 2021 09:26:42 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:3626) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ljMDe-0003PU-V7; Wed, 19 May 2021 09:26:41 -0400 Received: from dggems706-chm.china.huawei.com (unknown [172.30.72.60]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4FlYV95B4dzsSXT; Wed, 19 May 2021 21:23:45 +0800 (CST) Received: from dggpemm500023.china.huawei.com (7.185.36.83) by dggems706-chm.china.huawei.com (10.3.19.183) 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 21:26:31 +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 21:26:30 +0800 Subject: Re: [RFC PATCH v2 5/6] hw/arm/virt-acpi-build: Add PPTT table To: Andrew Jones , Salil Mehta 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> <20210519082735.yru7wpusq7lnmgj5@gator.home> From: "wangyanan (Y)" Message-ID: <4b64cb10-7825-e83c-8728-f9dde0d53b4b@huawei.com> Date: Wed, 19 May 2021 21:26:30 +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: <20210519082735.yru7wpusq7lnmgj5@gator.home> 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: dggeme719-chm.china.huawei.com (10.1.199.115) 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" Hi Drew, On 2021/5/19 16:27, Andrew Jones wrote: > On Tue, May 18, 2021 at 09:05:39PM +0200, Andrew Jones wrote: >> 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? >> > The more I think about this, the more I think we're in a bit of pickle and > need Peter Maydell to chime in. While we may want to make our -smp command > line option parsing more strict in order to bring some sanity to it, if > we do, then we'll break existing command lines, which, while may be > specifying useless inputs, have always gotten away with it. We probably > can't just change that now without forcing the user to opt into it. > Maybe we need to add another -smp parameter like 'strict' that has to > be set to 'on' in order to get this new behavior. > > Peter, do you have some suggestions for this? A summary of the problem > we'd like to solve is as follows: > > We'd like to start describing CPU topology to guests when provided > topology information with the '-smp ...' command line option. Currently, > a user may provide nearly whatever it wants on that command line option > and not get an error, even though the guest will not get a topology > description. When building the topology its important to know what > the user actually wants, so we're proposing to require both sockets > and cores be given if one of them is given. Also, since we don't yet > support hot plug for AArch64, we're proposing to enforce cpus == maxcpus. > > Is it fine to make those changes to the parsing for 6.1 and later? (Note, > mach-virt will override the default smp_parse with its own, so this is > mach-virt specific.) Or, should we only do this if a new parameter is > also given, e.g. 'strict'. Something like > > -smp strict=on,cpus=4,sockets=2,cores=2 > > would be needed by users who want to describe cpu topologies. Without > a strict description, then they get what they get today for their > DT/ACPI topology description, nothing. From my point of view, I like the idea of a new parameter like "strict=on/off". I will explain the reason below but maybe I have missed something, so I also hope for some suggestions from Peter. :) 1) We don't need to worry about breaking any existing -smp command lines including the rare and strange ones any more, since we will only have more strict requirement for the new provided cmdlines with "strict=on" and only generate topology description to guest with these new cmdlines provided. 2) This will provide an option for users to decide whether to enable the feature or not. Furthermore, this feature can also work on older machine types, if a user want to make use of cpu topology exposure to guest on older machines and is also sure it won't affect the application's behavior, then he can read the Doc and properly provided a -smp cmdline with "strict=on" to boot a VM. 3) We don't need to bother guessing different formats of -smp command lines in parsing. If the new parameter is not specified or "strict=off" is provided, we totally follow the rules in smp_parse() and disable the topology exposure. And if "strict=on" is provided, we enable the topology exposure and enforce completely detailed configuration like "-smp strict=on,cpus=4,sockets=2,cores=2". But maxcpus will be optional, it will default to cpus if not provided. We also ensure it matches cpus if provided, given that cpu hotplug is not available yet. Thanks, Yanan > Thanks, > drew > > .