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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C50BC433F5 for ; Wed, 9 Mar 2022 16:50:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id DCA1749F16; Wed, 9 Mar 2022 11:50:53 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com 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 s2T1qbiyqspu; Wed, 9 Mar 2022 11:50:52 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C3B0649E36; Wed, 9 Mar 2022 11:50:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5180D49E1A for ; Wed, 9 Mar 2022 11:50:51 -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 pmNmJoG+ew7c for ; Wed, 9 Mar 2022 11:50:50 -0500 (EST) Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 1A77349E17 for ; Wed, 9 Mar 2022 11:50:50 -0500 (EST) Received: by mail-wm1-f44.google.com with SMTP id p184-20020a1c29c1000000b0037f76d8b484so1830532wmp.5 for ; Wed, 09 Mar 2022 08:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ZgHou8MqoXhRtzbJoo/yhan8iXTUzQE6PBiS2FKYRVk=; b=ApCIZr+MN6aee2cgqpPw+PV2CFMmrVy6Tba9Ix98g0JMbS/aPhT2nRYGytV5+Ew1dK z0tHBjwNiHk8ULLoDS6I4IZtOD1vgXLJ6jKahOF+IevRmjrWjq4mt6e2HLiiL22auFD7 MnRfKwypFDEgPWQJnHfOysoynPTsTdtaTl0uYlV7qZCkg7zwXRBiAvgulaFHIPHCW0x5 Hnuu1IVwWai8BPnp6D9ccORnN9fLNaPf57yibDLFRvp1pBm3n06ltkKX9Je5tohqyKmH OCBB1atg/D7hEWIqw31e2vKDb8speQ438g9RZRyONaVt0go3FMRBOFD7EDZjPJEfAe+j YQcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ZgHou8MqoXhRtzbJoo/yhan8iXTUzQE6PBiS2FKYRVk=; b=8LhB7OPY0At//uNemqLuUugOf8GE+3Vyyvb4fbTyUvNkgrYjMSaR72B4M7NUgJvb/7 nepuc6VEq3qIkruTx2oyC5wP7D5bN+DwxO3Wr7WtDERzxW+AwjkCJwTh/7pfRmamDBJC QhC663p/Qm8ts0szDbGVYLMGa456jEvvewkE82bKAPOleZ3Kd87TcdmnUb3FUtVn+LC/ mnejtlgRecBDfFb7JUOuCKnNsh7flbgh2xtZ0GhVyzD+J9MQpSBaVNeq28TEIvtQ1Eep IkIoM8HL+E1WGddVg5HM4MRk5J0x4osXSXkuQZBv8/C9GUh5MeyViUQ5yOf4z1MpeEYx HUNw== X-Gm-Message-State: AOAM533i5v18lYjLkOWhs5zOTU7InCdeBPjAP19iyyRUrvR3f5e/gaN+ jQz5viHU3m+JnHipyeqf1tjB4A== X-Google-Smtp-Source: ABdhPJxsfLI0wVXG0HYqp8aGshE147e4FbNfGYA0n96plE+EG/lqB6ihUwJsiKwXUPa03ZDRH3qAhA== X-Received: by 2002:a05:600c:3b1c:b0:389:8677:6c73 with SMTP id m28-20020a05600c3b1c00b0038986776c73mr210606wms.192.1646844648795; Wed, 09 Mar 2022 08:50:48 -0800 (PST) Received: from google.com ([2a00:79e0:d:210:24bb:c5c7:5788:287d]) by smtp.gmail.com with ESMTPSA id v20-20020a7bcb54000000b0037fa63db8aasm5972989wmj.5.2022.03.09.08.50.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Mar 2022 08:50:48 -0800 (PST) Date: Wed, 9 Mar 2022 16:50:45 +0000 From: Quentin Perret To: Kalesh Singh Subject: Re: [PATCH v5 1/8] KVM: arm64: Introduce hyp_alloc_private_va_range() Message-ID: References: <20220307184935.1704614-1-kaleshsingh@google.com> <20220307184935.1704614-2-kaleshsingh@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: "Cc: Android Kernel" , "moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)" , Will Deacon , Peter Collingbourne , Marc Zyngier , LKML , Stephen Boyd , "Madhavan T. Venkataraman" , Mark Brown , Masami Hiramatsu , Catalin Marinas , Suren Baghdasaryan , kvmarm 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 Tuesday 08 Mar 2022 at 15:09:18 (-0800), Kalesh Singh wrote: > On Tue, Mar 8, 2022 at 12:21 PM Stephen Boyd wrote: > > It looks odd to use an error pointer casted to unsigned long to return > > from an address allocation function. Why not pass a pointer for base > > like the function was written before and return an int from this > > function with 0 for success and negative error value?Otherwise some > > sort of define should made like DMA_MAPPING_ERROR and that can be used > > to indicate to the caller that the allocation failed, or a simple zero > > may work? > > I wanted to keep consistent between the pkvm and traditional nvhe > code. I will refactor both *alloc_private_va_range() functions to take > a pointer and return an int error if that's preferred. There would > still be a case of this kind of cast in > __pkvm_create_private_mapping() which does return an unsigned long > address or ERR_PTR(...). It looks like it was made to return the > address to facilitate use as a hypercall (@Quentin CMIW). Yep, passing everything by value was much easier to cross the EL1/EL2 boundary as that avoids having the hypervisor map kernel memory and all that fun. But Stephen's point is fair, so no objection from to keep this little dance confined to the hypercall wrapper and make the function signature nicer and easier to use for the rest of the code. Cheers, Quentin _______________________________________________ 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 908F9C433EF for ; Wed, 9 Mar 2022 17:05:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=hpL9ZXSk/pFe+T9cFREcx4qh6PGMfDlepy6JLzbWT+w=; b=WsxVTkUIsEP/gH TjadDdY4fgcTZZ5mhUBpWxCyRf+G1bKUZhyI+soJ79INoCLjgggVI+2HI3eBHPdOynhFbJZ0jtigK 4AKq3WUKPz6sfW7j8hg2dzUCDR11QWanhRPmw502iPIptnYvIra4cUDERfIRV5aWJuFLUbaA160Qg oppoqfOoZGvlNrgYuecrYaAc5WypClIOp7G+ATadxrLPD5SJ6lcA72ytElvr2NT+RSTqX6OyoUwpe JWZmfheN4wdW3fEIC9CJi6n7Qa8Xpn4ZcgG1tvHi9I02j+PxSpvcHWyxUUYUbgpTQ8BzKyzAu1zIa DvTi2hjFaKU2qoF5XgwA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRzir-009fbP-TA; Wed, 09 Mar 2022 17:03:38 +0000 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRzWW-009a1b-Ju for linux-arm-kernel@lists.infradead.org; Wed, 09 Mar 2022 16:50:54 +0000 Received: by mail-wm1-x32a.google.com with SMTP id bg31-20020a05600c3c9f00b00381590dbb33so1840819wmb.3 for ; Wed, 09 Mar 2022 08:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ZgHou8MqoXhRtzbJoo/yhan8iXTUzQE6PBiS2FKYRVk=; b=ApCIZr+MN6aee2cgqpPw+PV2CFMmrVy6Tba9Ix98g0JMbS/aPhT2nRYGytV5+Ew1dK z0tHBjwNiHk8ULLoDS6I4IZtOD1vgXLJ6jKahOF+IevRmjrWjq4mt6e2HLiiL22auFD7 MnRfKwypFDEgPWQJnHfOysoynPTsTdtaTl0uYlV7qZCkg7zwXRBiAvgulaFHIPHCW0x5 Hnuu1IVwWai8BPnp6D9ccORnN9fLNaPf57yibDLFRvp1pBm3n06ltkKX9Je5tohqyKmH OCBB1atg/D7hEWIqw31e2vKDb8speQ438g9RZRyONaVt0go3FMRBOFD7EDZjPJEfAe+j YQcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ZgHou8MqoXhRtzbJoo/yhan8iXTUzQE6PBiS2FKYRVk=; b=PtS3laefoNRMVgDoGUdW88zWDc8f7JLy3zWDiL22LkXvcFtI+odYZ5PowFqh71rPbj Z2uB04AmFt4/mUrWOmFlEuAGZOcCAlpy6HGZ3h/5Rya39WHCOf8fs/H8UPxHbWxUjDfQ PqFIVbg3GAnQ2zKjuUGIqKXD2XHCMevS1flNwyfu0/d5UttOTolGRZucdmP6Z7vh3XbH NbLvAYwYbzDE0U3UVMz6VFoYgkHi+R1eT+aGZqmtWTi+WKs1mv96AJ3SkoEBHOAI9xMb qZYlDNv9dQzpUYm0tSOLi2Qi5/TPO9GGIVmxOtRJHXC9IN4aNgT79SO5/mSgcFHIRDw0 Qshw== X-Gm-Message-State: AOAM531SfksZXCTM3qaBeZP0W/ovquE97llaqsvs15g1Un+PYa4tjkvz +NDuXL5eDTrKFav/nx0CbLY01w== X-Google-Smtp-Source: ABdhPJxsfLI0wVXG0HYqp8aGshE147e4FbNfGYA0n96plE+EG/lqB6ihUwJsiKwXUPa03ZDRH3qAhA== X-Received: by 2002:a05:600c:3b1c:b0:389:8677:6c73 with SMTP id m28-20020a05600c3b1c00b0038986776c73mr210606wms.192.1646844648795; Wed, 09 Mar 2022 08:50:48 -0800 (PST) Received: from google.com ([2a00:79e0:d:210:24bb:c5c7:5788:287d]) by smtp.gmail.com with ESMTPSA id v20-20020a7bcb54000000b0037fa63db8aasm5972989wmj.5.2022.03.09.08.50.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Mar 2022 08:50:48 -0800 (PST) Date: Wed, 9 Mar 2022 16:50:45 +0000 From: Quentin Perret To: Kalesh Singh Cc: Stephen Boyd , Will Deacon , Marc Zyngier , Fuad Tabba , Suren Baghdasaryan , "Cc: Android Kernel" , James Morse , Alexandru Elisei , Suzuki K Poulose , Catalin Marinas , Mark Rutland , Mark Brown , Masami Hiramatsu , Peter Collingbourne , "Madhavan T. Venkataraman" , Andrew Scull , "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" , kvmarm , LKML Subject: Re: [PATCH v5 1/8] KVM: arm64: Introduce hyp_alloc_private_va_range() Message-ID: References: <20220307184935.1704614-1-kaleshsingh@google.com> <20220307184935.1704614-2-kaleshsingh@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220309_085052_692329_84E52B83 X-CRM114-Status: GOOD ( 19.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tuesday 08 Mar 2022 at 15:09:18 (-0800), Kalesh Singh wrote: > On Tue, Mar 8, 2022 at 12:21 PM Stephen Boyd wrote: > > It looks odd to use an error pointer casted to unsigned long to return > > from an address allocation function. Why not pass a pointer for base > > like the function was written before and return an int from this > > function with 0 for success and negative error value?Otherwise some > > sort of define should made like DMA_MAPPING_ERROR and that can be used > > to indicate to the caller that the allocation failed, or a simple zero > > may work? > > I wanted to keep consistent between the pkvm and traditional nvhe > code. I will refactor both *alloc_private_va_range() functions to take > a pointer and return an int error if that's preferred. There would > still be a case of this kind of cast in > __pkvm_create_private_mapping() which does return an unsigned long > address or ERR_PTR(...). It looks like it was made to return the > address to facilitate use as a hypercall (@Quentin CMIW). Yep, passing everything by value was much easier to cross the EL1/EL2 boundary as that avoids having the hypervisor map kernel memory and all that fun. But Stephen's point is fair, so no objection from to keep this little dance confined to the hypercall wrapper and make the function signature nicer and easier to use for the rest of the code. Cheers, Quentin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 722AFC43219 for ; Wed, 9 Mar 2022 17:04:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236972AbiCIRFS (ORCPT ); Wed, 9 Mar 2022 12:05:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42258 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235748AbiCIRCl (ORCPT ); Wed, 9 Mar 2022 12:02:41 -0500 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 99973192C96 for ; Wed, 9 Mar 2022 08:50:50 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id r187-20020a1c2bc4000000b003810e6b192aso1853609wmr.1 for ; Wed, 09 Mar 2022 08:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ZgHou8MqoXhRtzbJoo/yhan8iXTUzQE6PBiS2FKYRVk=; b=ApCIZr+MN6aee2cgqpPw+PV2CFMmrVy6Tba9Ix98g0JMbS/aPhT2nRYGytV5+Ew1dK z0tHBjwNiHk8ULLoDS6I4IZtOD1vgXLJ6jKahOF+IevRmjrWjq4mt6e2HLiiL22auFD7 MnRfKwypFDEgPWQJnHfOysoynPTsTdtaTl0uYlV7qZCkg7zwXRBiAvgulaFHIPHCW0x5 Hnuu1IVwWai8BPnp6D9ccORnN9fLNaPf57yibDLFRvp1pBm3n06ltkKX9Je5tohqyKmH OCBB1atg/D7hEWIqw31e2vKDb8speQ438g9RZRyONaVt0go3FMRBOFD7EDZjPJEfAe+j YQcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ZgHou8MqoXhRtzbJoo/yhan8iXTUzQE6PBiS2FKYRVk=; b=1YVNKkZVL1RiUD/d9Mk5HCkB3CcXUS1oPF+6Fnq2MFg9J9UPGZIrqT83nY6LooY+Yr TE04FZvznh514Kgmz4oCIWH4+tW00K3OIr7Odo/yBEokv5cnyFkAG8uDXHV/3dzmSi++ WscuEshIN221ptPL0AwqUT3xKa9SrMoBw8RXHoDEEfzhHKSeEWtAnlF8wyL7fs479Xpy GyFqTm+TvdjAD2vnGsPVpJ49iApNldMOnO9VYVjf8UOst7XPZ7zjhMUyabLLaXlmFUAY KvsCyVhtNEe11aGOu3UTokMjUq1C6BTtZoLxt1wC81Vi3YYSL7ke+JQBoye7dcOvUOBl cRZQ== X-Gm-Message-State: AOAM5314EcS3mWIKt/VCfjQA7fOUTHJOy8N+bEk18fcwd4wwxbPEilo5 JWlaKG6F96SiHEntGSDa8n6mrw== X-Google-Smtp-Source: ABdhPJxsfLI0wVXG0HYqp8aGshE147e4FbNfGYA0n96plE+EG/lqB6ihUwJsiKwXUPa03ZDRH3qAhA== X-Received: by 2002:a05:600c:3b1c:b0:389:8677:6c73 with SMTP id m28-20020a05600c3b1c00b0038986776c73mr210606wms.192.1646844648795; Wed, 09 Mar 2022 08:50:48 -0800 (PST) Received: from google.com ([2a00:79e0:d:210:24bb:c5c7:5788:287d]) by smtp.gmail.com with ESMTPSA id v20-20020a7bcb54000000b0037fa63db8aasm5972989wmj.5.2022.03.09.08.50.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Mar 2022 08:50:48 -0800 (PST) Date: Wed, 9 Mar 2022 16:50:45 +0000 From: Quentin Perret To: Kalesh Singh Cc: Stephen Boyd , Will Deacon , Marc Zyngier , Fuad Tabba , Suren Baghdasaryan , "Cc: Android Kernel" , James Morse , Alexandru Elisei , Suzuki K Poulose , Catalin Marinas , Mark Rutland , Mark Brown , Masami Hiramatsu , Peter Collingbourne , "Madhavan T. Venkataraman" , Andrew Scull , "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" , kvmarm , LKML Subject: Re: [PATCH v5 1/8] KVM: arm64: Introduce hyp_alloc_private_va_range() Message-ID: References: <20220307184935.1704614-1-kaleshsingh@google.com> <20220307184935.1704614-2-kaleshsingh@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 08 Mar 2022 at 15:09:18 (-0800), Kalesh Singh wrote: > On Tue, Mar 8, 2022 at 12:21 PM Stephen Boyd wrote: > > It looks odd to use an error pointer casted to unsigned long to return > > from an address allocation function. Why not pass a pointer for base > > like the function was written before and return an int from this > > function with 0 for success and negative error value?Otherwise some > > sort of define should made like DMA_MAPPING_ERROR and that can be used > > to indicate to the caller that the allocation failed, or a simple zero > > may work? > > I wanted to keep consistent between the pkvm and traditional nvhe > code. I will refactor both *alloc_private_va_range() functions to take > a pointer and return an int error if that's preferred. There would > still be a case of this kind of cast in > __pkvm_create_private_mapping() which does return an unsigned long > address or ERR_PTR(...). It looks like it was made to return the > address to facilitate use as a hypercall (@Quentin CMIW). Yep, passing everything by value was much easier to cross the EL1/EL2 boundary as that avoids having the hypervisor map kernel memory and all that fun. But Stephen's point is fair, so no objection from to keep this little dance confined to the hypercall wrapper and make the function signature nicer and easier to use for the rest of the code. Cheers, Quentin