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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 6808BE75452 for ; Tue, 3 Oct 2023 12:28:10 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qneVA-0005kg-52; Tue, 03 Oct 2023 08:27:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qneV6-0005ik-DF; Tue, 03 Oct 2023 08:27:44 -0400 Received: from frasgout.his.huawei.com ([185.176.79.56]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qneV2-0006oZ-N2; Tue, 03 Oct 2023 08:27:43 -0400 Received: from lhrpeml500006.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4S0H886vgMz6HJhS; Tue, 3 Oct 2023 20:24:56 +0800 (CST) Received: from lhrpeml500001.china.huawei.com (7.191.163.213) by lhrpeml500006.china.huawei.com (7.191.161.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Tue, 3 Oct 2023 13:27:36 +0100 Received: from lhrpeml500001.china.huawei.com ([7.191.163.213]) by lhrpeml500001.china.huawei.com ([7.191.163.213]) with mapi id 15.01.2507.031; Tue, 3 Oct 2023 13:27:36 +0100 To: Jonathan Cameron CC: "qemu-devel@nongnu.org" , "qemu-arm@nongnu.org" , "maz@kernel.org" , "jean-philippe@linaro.org" , "lpieralisi@kernel.org" , "peter.maydell@linaro.org" , "richard.henderson@linaro.org" , "imammedo@redhat.com" , "andrew.jones@linux.dev" , "david@redhat.com" , "philmd@linaro.org" , "eric.auger@redhat.com" , "oliver.upton@linux.dev" , "pbonzini@redhat.com" , "mst@redhat.com" , "will@kernel.org" , "gshan@redhat.com" , "rafael@kernel.org" , "alex.bennee@linaro.org" , "linux@armlinux.org.uk" , "darren@os.amperecomputing.com" , "ilkka@os.amperecomputing.com" , "vishnu@os.amperecomputing.com" , "karl.heubaum@oracle.com" , "miguel.luis@oracle.com" , "salil.mehta@opnsrc.net" , zhukeqian , "wangxiongfeng (C)" , "wangyanan (Y)" , "jiakernel2@gmail.com" , "maobibo@loongson.cn" , "lixianglai@loongson.cn" , Linuxarm Subject: RE: [PATCH V2 01/10] accel/kvm: Extract common KVM vCPU {creation,parking} code Thread-Topic: [PATCH V2 01/10] accel/kvm: Extract common KVM vCPU {creation,parking} code Thread-Index: AQHZ8zPpn9wpwkR00kGhOJ6dnPJS7rA2mfgAgAFHXwCAAAdMgIAAFxrA Date: Tue, 3 Oct 2023 12:27:36 +0000 Message-ID: <630c00201fd34c8fa307bed9c25bc334@huawei.com> References: <20230930001933.2660-1-salil.mehta@huawei.com> <20230930001933.2660-2-salil.mehta@huawei.com> <20231002165322.00003a2e@Huawei.com> <761a05a972ae4aa088b8e984bd89889f@huawei.com> <20231003125111.00002013@Huawei.com> In-Reply-To: <20231003125111.00002013@Huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.168.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Received-SPF: pass client-ip=185.176.79.56; envelope-from=salil.mehta@huawei.com; helo=frasgout.his.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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=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.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Salil Mehta From: Salil Mehta via Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org > From: Jonathan Cameron > Sent: Tuesday, October 3, 2023 12:51 PM > To: Salil Mehta > Cc: qemu-devel@nongnu.org; qemu-arm@nongnu.org; maz@kernel.org; jean- > philippe@linaro.org; lpieralisi@kernel.org; peter.maydell@linaro.org; > richard.henderson@linaro.org; imammedo@redhat.com; andrew.jones@linux.dev= ; > david@redhat.com; philmd@linaro.org; eric.auger@redhat.com; > oliver.upton@linux.dev; pbonzini@redhat.com; mst@redhat.com; > will@kernel.org; gshan@redhat.com; rafael@kernel.org; > alex.bennee@linaro.org; linux@armlinux.org.uk; > darren@os.amperecomputing.com; ilkka@os.amperecomputing.com; > vishnu@os.amperecomputing.com; karl.heubaum@oracle.com; > miguel.luis@oracle.com; salil.mehta@opnsrc.net; zhukeqian > ; wangxiongfeng (C) ; > wangyanan (Y) ; jiakernel2@gmail.com; > maobibo@loongson.cn; lixianglai@loongson.cn; Linuxarm > Subject: Re: [PATCH V2 01/10] accel/kvm: Extract common KVM vCPU > {creation,parking} code >=20 > On Tue, 3 Oct 2023 12:05:11 +0100 > Salil Mehta wrote: >=20 > > Hi Jonathan, > > > > > From: Jonathan Cameron > > > Sent: Monday, October 2, 2023 4:53 PM > > > To: Salil Mehta > > > Cc: qemu-devel@nongnu.org; qemu-arm@nongnu.org; maz@kernel.org; jean- > > > philippe@linaro.org; lpieralisi@kernel.org; peter.maydell@linaro.org; > > > richard.henderson@linaro.org; imammedo@redhat.com; andrew.jones@linux= .dev; > > > david@redhat.com; philmd@linaro.org; eric.auger@redhat.com; > > > oliver.upton@linux.dev; pbonzini@redhat.com; mst@redhat.com; > > > will@kernel.org; gshan@redhat.com; rafael@kernel.org; > > > alex.bennee@linaro.org; linux@armlinux.org.uk; > > > darren@os.amperecomputing.com; ilkka@os.amperecomputing.com; > > > vishnu@os.amperecomputing.com; karl.heubaum@oracle.com; > > > miguel.luis@oracle.com; salil.mehta@opnsrc.net; zhukeqian > > > ; wangxiongfeng (C) ; > > > wangyanan (Y) ; jiakernel2@gmail.com; > > > maobibo@loongson.cn; lixianglai@loongson.cn; Linuxarm > > > Subject: Re: [PATCH V2 01/10] accel/kvm: Extract common KVM vCPU > > > {creation,parking} code > > > > > > On Sat, 30 Sep 2023 01:19:24 +0100 > > > Salil Mehta wrote: > > > > > > > KVM vCPU creation is done once during the initialization of the VM = when Qemu > > > > threads are spawned. This is common to all the architectures. > > > > > > > > Hot-unplug of vCPU results in destruction of the vCPU objects in QO= M but > > > > the KVM vCPU objects in the Host KVM are not destroyed and their re= presentative > > > > KVM vCPU objects/context in Qemu are parked. > > > > > > > > Refactor common logic so that some APIs could be reused by vCPU Hot= plug code. > > > > > > > > Signed-off-by: Salil Mehta > > > > > > Hi Salil, > > > > > > A few trivial things inline, plus a question about why > > > cpu->cpu_index can now be used but kvm_arch_vcpu_id(cpu); > > > was previously needed. > > > > Good point. I used the API because it was returning > > 'unsigned long' and it was being used across the archs. > > I thought maybe the size of the index could vary across > > archs. For example, for PowerPC above API returns vcpu_id > > which presumably could have different data type than > > an 'integer'. > > > > But after Alex's comment, I was made to believe that this > > assumption might not be correct and CPU index is an > > 'integer' across archs and perhaps semantics of above > > API is not correct. > > > > But perhaps original code was functionally correct? >=20 > I wasn't concerned with the type, but rather that the > value comes from other places than cpu->cpu_index > on some architectures. Sure, I meant there is a reason why type was chosen as 'unsigned long' and not an 'integer'. Perhaps the value can exceed the 'integer' size limits because of the way CPU index is being created on certain archs? If we try to put value from a larger container 'unsigned long' to a smaller container 'integer' things can go wrong. [...] > > > > > > > + vcpu->kvm_fd =3D cpu->kvm_fd; > > > > + QLIST_INSERT_HEAD(&kvm_state->kvm_parked_vcpus, vcpu, node); > > > > +} > > > > + > > > > +int kvm_create_vcpu(CPUState *cpu) > > > > +{ > > > > + int vcpu_id =3D cpu->cpu_index; > > > > > > See below. I'm not sure why it's safe not to use kvm_arch_vcpu_id() > > > Seems a few architectures have less than trivial implementations of > > > that function currently. > > > > I doubt this as well. Other architectures like PowerPC are returning > > different type? > > > It wasn't the type that bothered, me but rather that the source of > the data isn't always cpu->cpu_index so I have no idea if the values > are consistent. Got it. I meant 'unsigned long' return type in the kvm_arch_vcpu_id(). On some Architectures, the required container size for their vcpu-id could exceed an 'integer'. Sorry, for not making it clear. Thanks Salil. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1qneVA-0005k1-09 for mharc-qemu-devel@gnu.org; Tue, 03 Oct 2023 08:27:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qneV6-0005ik-DF; Tue, 03 Oct 2023 08:27:44 -0400 Received: from frasgout.his.huawei.com ([185.176.79.56]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qneV2-0006oZ-N2; Tue, 03 Oct 2023 08:27:43 -0400 Received: from lhrpeml500006.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4S0H886vgMz6HJhS; Tue, 3 Oct 2023 20:24:56 +0800 (CST) Received: from lhrpeml500001.china.huawei.com (7.191.163.213) by lhrpeml500006.china.huawei.com (7.191.161.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Tue, 3 Oct 2023 13:27:36 +0100 Received: from lhrpeml500001.china.huawei.com ([7.191.163.213]) by lhrpeml500001.china.huawei.com ([7.191.163.213]) with mapi id 15.01.2507.031; Tue, 3 Oct 2023 13:27:36 +0100 From: Salil Mehta To: Jonathan Cameron CC: "qemu-devel@nongnu.org" , "qemu-arm@nongnu.org" , "maz@kernel.org" , "jean-philippe@linaro.org" , "lpieralisi@kernel.org" , "peter.maydell@linaro.org" , "richard.henderson@linaro.org" , "imammedo@redhat.com" , "andrew.jones@linux.dev" , "david@redhat.com" , "philmd@linaro.org" , "eric.auger@redhat.com" , "oliver.upton@linux.dev" , "pbonzini@redhat.com" , "mst@redhat.com" , "will@kernel.org" , "gshan@redhat.com" , "rafael@kernel.org" , "alex.bennee@linaro.org" , "linux@armlinux.org.uk" , "darren@os.amperecomputing.com" , "ilkka@os.amperecomputing.com" , "vishnu@os.amperecomputing.com" , "karl.heubaum@oracle.com" , "miguel.luis@oracle.com" , "salil.mehta@opnsrc.net" , zhukeqian , "wangxiongfeng (C)" , "wangyanan (Y)" , "jiakernel2@gmail.com" , "maobibo@loongson.cn" , "lixianglai@loongson.cn" , Linuxarm Subject: RE: [PATCH V2 01/10] accel/kvm: Extract common KVM vCPU {creation,parking} code Thread-Topic: [PATCH V2 01/10] accel/kvm: Extract common KVM vCPU {creation,parking} code Thread-Index: AQHZ8zPpn9wpwkR00kGhOJ6dnPJS7rA2mfgAgAFHXwCAAAdMgIAAFxrA Date: Tue, 3 Oct 2023 12:27:36 +0000 Message-ID: <630c00201fd34c8fa307bed9c25bc334@huawei.com> References: <20230930001933.2660-1-salil.mehta@huawei.com> <20230930001933.2660-2-salil.mehta@huawei.com> <20231002165322.00003a2e@Huawei.com> <761a05a972ae4aa088b8e984bd89889f@huawei.com> <20231003125111.00002013@Huawei.com> In-Reply-To: <20231003125111.00002013@Huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.168.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Received-SPF: pass client-ip=185.176.79.56; envelope-from=salil.mehta@huawei.com; helo=frasgout.his.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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=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.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2023 12:27:46 -0000 Message-ID: <20231003122736.WDof4EUzgnMaGX493R6pPG5O11eCtK9s72DxwnrflHU@z> > From: Jonathan Cameron > Sent: Tuesday, October 3, 2023 12:51 PM > To: Salil Mehta > Cc: qemu-devel@nongnu.org; qemu-arm@nongnu.org; maz@kernel.org; jean- > philippe@linaro.org; lpieralisi@kernel.org; peter.maydell@linaro.org; > richard.henderson@linaro.org; imammedo@redhat.com; andrew.jones@linux.dev= ; > david@redhat.com; philmd@linaro.org; eric.auger@redhat.com; > oliver.upton@linux.dev; pbonzini@redhat.com; mst@redhat.com; > will@kernel.org; gshan@redhat.com; rafael@kernel.org; > alex.bennee@linaro.org; linux@armlinux.org.uk; > darren@os.amperecomputing.com; ilkka@os.amperecomputing.com; > vishnu@os.amperecomputing.com; karl.heubaum@oracle.com; > miguel.luis@oracle.com; salil.mehta@opnsrc.net; zhukeqian > ; wangxiongfeng (C) ; > wangyanan (Y) ; jiakernel2@gmail.com; > maobibo@loongson.cn; lixianglai@loongson.cn; Linuxarm > Subject: Re: [PATCH V2 01/10] accel/kvm: Extract common KVM vCPU > {creation,parking} code >=20 > On Tue, 3 Oct 2023 12:05:11 +0100 > Salil Mehta wrote: >=20 > > Hi Jonathan, > > > > > From: Jonathan Cameron > > > Sent: Monday, October 2, 2023 4:53 PM > > > To: Salil Mehta > > > Cc: qemu-devel@nongnu.org; qemu-arm@nongnu.org; maz@kernel.org; jean- > > > philippe@linaro.org; lpieralisi@kernel.org; peter.maydell@linaro.org; > > > richard.henderson@linaro.org; imammedo@redhat.com; andrew.jones@linux= .dev; > > > david@redhat.com; philmd@linaro.org; eric.auger@redhat.com; > > > oliver.upton@linux.dev; pbonzini@redhat.com; mst@redhat.com; > > > will@kernel.org; gshan@redhat.com; rafael@kernel.org; > > > alex.bennee@linaro.org; linux@armlinux.org.uk; > > > darren@os.amperecomputing.com; ilkka@os.amperecomputing.com; > > > vishnu@os.amperecomputing.com; karl.heubaum@oracle.com; > > > miguel.luis@oracle.com; salil.mehta@opnsrc.net; zhukeqian > > > ; wangxiongfeng (C) ; > > > wangyanan (Y) ; jiakernel2@gmail.com; > > > maobibo@loongson.cn; lixianglai@loongson.cn; Linuxarm > > > Subject: Re: [PATCH V2 01/10] accel/kvm: Extract common KVM vCPU > > > {creation,parking} code > > > > > > On Sat, 30 Sep 2023 01:19:24 +0100 > > > Salil Mehta wrote: > > > > > > > KVM vCPU creation is done once during the initialization of the VM = when Qemu > > > > threads are spawned. This is common to all the architectures. > > > > > > > > Hot-unplug of vCPU results in destruction of the vCPU objects in QO= M but > > > > the KVM vCPU objects in the Host KVM are not destroyed and their re= presentative > > > > KVM vCPU objects/context in Qemu are parked. > > > > > > > > Refactor common logic so that some APIs could be reused by vCPU Hot= plug code. > > > > > > > > Signed-off-by: Salil Mehta > > > > > > Hi Salil, > > > > > > A few trivial things inline, plus a question about why > > > cpu->cpu_index can now be used but kvm_arch_vcpu_id(cpu); > > > was previously needed. > > > > Good point. I used the API because it was returning > > 'unsigned long' and it was being used across the archs. > > I thought maybe the size of the index could vary across > > archs. For example, for PowerPC above API returns vcpu_id > > which presumably could have different data type than > > an 'integer'. > > > > But after Alex's comment, I was made to believe that this > > assumption might not be correct and CPU index is an > > 'integer' across archs and perhaps semantics of above > > API is not correct. > > > > But perhaps original code was functionally correct? >=20 > I wasn't concerned with the type, but rather that the > value comes from other places than cpu->cpu_index > on some architectures. Sure, I meant there is a reason why type was chosen as 'unsigned long' and not an 'integer'. Perhaps the value can exceed the 'integer' size limits because of the way CPU index is being created on certain archs? If we try to put value from a larger container 'unsigned long' to a smaller container 'integer' things can go wrong. [...] > > > > > > > + vcpu->kvm_fd =3D cpu->kvm_fd; > > > > + QLIST_INSERT_HEAD(&kvm_state->kvm_parked_vcpus, vcpu, node); > > > > +} > > > > + > > > > +int kvm_create_vcpu(CPUState *cpu) > > > > +{ > > > > + int vcpu_id =3D cpu->cpu_index; > > > > > > See below. I'm not sure why it's safe not to use kvm_arch_vcpu_id() > > > Seems a few architectures have less than trivial implementations of > > > that function currently. > > > > I doubt this as well. Other architectures like PowerPC are returning > > different type? > > > It wasn't the type that bothered, me but rather that the source of > the data isn't always cpu->cpu_index so I have no idea if the values > are consistent. Got it. I meant 'unsigned long' return type in the kvm_arch_vcpu_id(). On some Architectures, the required container size for their vcpu-id could exceed an 'integer'. Sorry, for not making it clear. Thanks Salil.