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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 E1C41C33CAD for ; Mon, 13 Jan 2020 10:31:29 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 8BD562081E for ; Mon, 13 Jan 2020 10:31:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8BD562081E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 1DD1F4AECA; Mon, 13 Jan 2020 05:31:29 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygKcXPpscCOI; Mon, 13 Jan 2020 05:31:27 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id DE21C4AECB; Mon, 13 Jan 2020 05:31:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id EFC094AEC9 for ; Mon, 13 Jan 2020 05:31:26 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YNncJIfPRIT for ; Mon, 13 Jan 2020 05:31:25 -0500 (EST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id CE3B44AC68 for ; Mon, 13 Jan 2020 05:31:25 -0500 (EST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6DFF713D5; Mon, 13 Jan 2020 02:31:25 -0800 (PST) Received: from arm.com (e112269-lin.cambridge.arm.com [10.1.194.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 571363F534; Mon, 13 Jan 2020 02:31:23 -0800 (PST) Date: Mon, 13 Jan 2020 10:31:18 +0000 From: Steven Price To: yezengruan Subject: Re: [PATCH v2 3/6] KVM: arm64: Support pvlock preempted via shared structure Message-ID: <20200113103117.GA44375@arm.com> References: <20191226135833.1052-1-yezengruan@huawei.com> <20191226135833.1052-4-yezengruan@huawei.com> <468e2bb4-8986-5e1e-8c4a-31aa56a9ae4f@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Cc: "daniel.lezcano@linaro.org" , "kvm@vger.kernel.org" , "linux-doc@vger.kernel.org" , "maz@kernel.org" , "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , Catalin Marinas , "linux@armlinux.org.uk" , "will@kernel.org" , "kvmarm@lists.cs.columbia.edu" , "linux-arm-kernel@lists.infradead.org" X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Sat, Jan 11, 2020 at 07:30:42AM +0000, yezengruan wrote: > Hi Steve, > > On 2020/1/9 23:02, Steven Price wrote: > > On 26/12/2019 13:58, Zengruan Ye wrote: > >> Implement the service call for configuring a shared structure between a > >> VCPU and the hypervisor in which the hypervisor can tell the VCPU is > >> running or not. > >> > >> The preempted field is zero if 1) some old KVM deos not support this filed. > > > > NIT: s/deos/does/ > > Thanks for posting this. > > > > > However, I would hope that the service call will fail if it's an old KVM not simply return zero. > > Sorry, I'm not sure what you mean. The service call will fail if it's an old KVM, and the Guest will use __native_vcpu_is_preempted. You previously said the "field is zero if [...] some old KVM does not support this field". This seems a bit of an odd statement, because the field just doesn't exist (it's an old KVM so won't have allocated it), and if the guest attempts to find the field using the service call then the call will fail. So I'm not sure in what situation you are expecting the field to be zero on an old KVM. Steve _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 CAB54C33CAF for ; Mon, 13 Jan 2020 10:31:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E4852207E0 for ; Mon, 13 Jan 2020 10:31:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726109AbgAMKb0 (ORCPT ); Mon, 13 Jan 2020 05:31:26 -0500 Received: from foss.arm.com ([217.140.110.172]:37300 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726163AbgAMKb0 (ORCPT ); Mon, 13 Jan 2020 05:31:26 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6DFF713D5; Mon, 13 Jan 2020 02:31:25 -0800 (PST) Received: from arm.com (e112269-lin.cambridge.arm.com [10.1.194.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 571363F534; Mon, 13 Jan 2020 02:31:23 -0800 (PST) Date: Mon, 13 Jan 2020 10:31:18 +0000 From: Steven Price To: yezengruan Cc: "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.cs.columbia.edu" , "kvm@vger.kernel.org" , "linux-doc@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "maz@kernel.org" , James Morse , "linux@armlinux.org.uk" , Suzuki Poulose , "julien.thierry.kdev@gmail.com" , Catalin Marinas , Mark Rutland , "will@kernel.org" , "daniel.lezcano@linaro.org" , "Wanghaibin (D)" Subject: Re: [PATCH v2 3/6] KVM: arm64: Support pvlock preempted via shared structure Message-ID: <20200113103117.GA44375@arm.com> References: <20191226135833.1052-1-yezengruan@huawei.com> <20191226135833.1052-4-yezengruan@huawei.com> <468e2bb4-8986-5e1e-8c4a-31aa56a9ae4f@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Sat, Jan 11, 2020 at 07:30:42AM +0000, yezengruan wrote: > Hi Steve, > > On 2020/1/9 23:02, Steven Price wrote: > > On 26/12/2019 13:58, Zengruan Ye wrote: > >> Implement the service call for configuring a shared structure between a > >> VCPU and the hypervisor in which the hypervisor can tell the VCPU is > >> running or not. > >> > >> The preempted field is zero if 1) some old KVM deos not support this filed. > > > > NIT: s/deos/does/ > > Thanks for posting this. > > > > > However, I would hope that the service call will fail if it's an old KVM not simply return zero. > > Sorry, I'm not sure what you mean. The service call will fail if it's an old KVM, and the Guest will use __native_vcpu_is_preempted. You previously said the "field is zero if [...] some old KVM does not support this field". This seems a bit of an odd statement, because the field just doesn't exist (it's an old KVM so won't have allocated it), and if the guest attempts to find the field using the service call then the call will fail. So I'm not sure in what situation you are expecting the field to be zero on an old KVM. Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Price Subject: Re: [PATCH v2 3/6] KVM: arm64: Support pvlock preempted via shared structure Date: Mon, 13 Jan 2020 10:31:18 +0000 Message-ID: <20200113103117.GA44375@arm.com> References: <20191226135833.1052-1-yezengruan@huawei.com> <20191226135833.1052-4-yezengruan@huawei.com> <468e2bb4-8986-5e1e-8c4a-31aa56a9ae4f@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: yezengruan Cc: "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.cs.columbia.edu" , "kvm@vger.kernel.org" , "linux-doc@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "maz@kernel.org" , James Morse , "linux@armlinux.org.uk" , Suzuki Poulose , "julien.thierry.kdev@gmail.com" , Catalin Marinas , Mark Rutland , "will@kernel.org" , daniel.lezcano@linaro.org List-Id: virtualization@lists.linuxfoundation.org On Sat, Jan 11, 2020 at 07:30:42AM +0000, yezengruan wrote: > Hi Steve, > > On 2020/1/9 23:02, Steven Price wrote: > > On 26/12/2019 13:58, Zengruan Ye wrote: > >> Implement the service call for configuring a shared structure between a > >> VCPU and the hypervisor in which the hypervisor can tell the VCPU is > >> running or not. > >> > >> The preempted field is zero if 1) some old KVM deos not support this filed. > > > > NIT: s/deos/does/ > > Thanks for posting this. > > > > > However, I would hope that the service call will fail if it's an old KVM not simply return zero. > > Sorry, I'm not sure what you mean. The service call will fail if it's an old KVM, and the Guest will use __native_vcpu_is_preempted. You previously said the "field is zero if [...] some old KVM does not support this field". This seems a bit of an odd statement, because the field just doesn't exist (it's an old KVM so won't have allocated it), and if the guest attempts to find the field using the service call then the call will fail. So I'm not sure in what situation you are expecting the field to be zero on an old KVM. Steve 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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 87E54C33CAD for ; Mon, 13 Jan 2020 10:31:35 +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 55657207E0 for ; Mon, 13 Jan 2020 10:31:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="P4oxuGbJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 55657207E0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4CnyGaakv2Wu6Yzos0fOOjv8pWsRtf+wEUqgrGKwPS0=; b=P4oxuGbJbkNq75 i4pAZlZxgHQ+9i71Ne66fl3oTskaigg671Fp3qzOtWbgCg1puGLZ4mttYClu4fsdRznw3bUHtCYmU E0vR8XL8CT/oF10lnmoP+DfPPf91+DmtuXRlIbG8Zl85ixdeKlEYQ87wDUFcaLXmMrO4ZzglvgYTr 0BqjvQdauzAvvPGfqHhMu+A0aKp4VSGEsz+IPxP8CXLUv02Cjq3xd6vvT4uBXfbzSEnFKE4EJ2B0Y CHeEVxxcp+99jFx7r0+AbJIAySjOh1DIAtJYEduJXawI0WE7X5a8nn42R4/HyZ2VO+Iai72Pf0HMX PTvCNCBZ2CS0Fkw9XnpA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iqx0N-0003TH-PD; Mon, 13 Jan 2020 10:31:31 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iqx0J-0003Od-PU for linux-arm-kernel@lists.infradead.org; Mon, 13 Jan 2020 10:31:29 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6DFF713D5; Mon, 13 Jan 2020 02:31:25 -0800 (PST) Received: from arm.com (e112269-lin.cambridge.arm.com [10.1.194.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 571363F534; Mon, 13 Jan 2020 02:31:23 -0800 (PST) Date: Mon, 13 Jan 2020 10:31:18 +0000 From: Steven Price To: yezengruan Subject: Re: [PATCH v2 3/6] KVM: arm64: Support pvlock preempted via shared structure Message-ID: <20200113103117.GA44375@arm.com> References: <20191226135833.1052-1-yezengruan@huawei.com> <20191226135833.1052-4-yezengruan@huawei.com> <468e2bb4-8986-5e1e-8c4a-31aa56a9ae4f@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200113_023127_889975_D606B5AF X-CRM114-Status: GOOD ( 14.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , "daniel.lezcano@linaro.org" , "kvm@vger.kernel.org" , "linux-doc@vger.kernel.org" , "maz@kernel.org" , Suzuki Poulose , "linux-kernel@vger.kernel.org" , "Wanghaibin \(D\)" , "virtualization@lists.linux-foundation.org" , James Morse , "julien.thierry.kdev@gmail.com" , Catalin Marinas , "linux@armlinux.org.uk" , "will@kernel.org" , "kvmarm@lists.cs.columbia.edu" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, Jan 11, 2020 at 07:30:42AM +0000, yezengruan wrote: > Hi Steve, > > On 2020/1/9 23:02, Steven Price wrote: > > On 26/12/2019 13:58, Zengruan Ye wrote: > >> Implement the service call for configuring a shared structure between a > >> VCPU and the hypervisor in which the hypervisor can tell the VCPU is > >> running or not. > >> > >> The preempted field is zero if 1) some old KVM deos not support this filed. > > > > NIT: s/deos/does/ > > Thanks for posting this. > > > > > However, I would hope that the service call will fail if it's an old KVM not simply return zero. > > Sorry, I'm not sure what you mean. The service call will fail if it's an old KVM, and the Guest will use __native_vcpu_is_preempted. You previously said the "field is zero if [...] some old KVM does not support this field". This seems a bit of an odd statement, because the field just doesn't exist (it's an old KVM so won't have allocated it), and if the guest attempts to find the field using the service call then the call will fail. So I'm not sure in what situation you are expecting the field to be zero on an old KVM. Steve _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel