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 0C379C433EF for ; Wed, 9 Mar 2022 17:04:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 8904240E06; Wed, 9 Mar 2022 12:04:24 -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 js1yidymXL0X; Wed, 9 Mar 2022 12:04:20 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B99984120D; Wed, 9 Mar 2022 12:04:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 743054120D for ; Wed, 9 Mar 2022 12:04:19 -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 sF8KB9ua1OdM for ; Wed, 9 Mar 2022 12:04:14 -0500 (EST) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 88D4840D0B for ; Wed, 9 Mar 2022 12:04:14 -0500 (EST) Received: by mail-wm1-f45.google.com with SMTP id q7-20020a7bce87000000b00382255f4ca9so3840885wmj.2 for ; Wed, 09 Mar 2022 09:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ndx32WBmfBxuvJH6NgXVPP6Qai1KeFznS/MWmU68F2k=; b=YQjVRwGsmDyttSMWRArNfLF0dqeQKY8E/07xyYcuzGr0kpyfDmH8G4dbdGdwdlBwnP zX1OtOneZOfWA5I7yR+egmuSJ2jHhH7Ut7NmOVk1XPYZi0TADjvFf5B5DFIvdUkNY62P +cvUl3a7OfQRD0oBDWHHEUNpZ7y2RxB1g2F8aRdKdvN5tt4jdIZjz2wzUoM1Xdj+uEwz 4YWWV1fNTpxtUqI9nbSpNzW55JCP6aUHS8hIbhGRLCdSUpYypgBjKrYzBB4AnrJV5Wj8 Cxpn/g7Z6EZckp3ywXFFKd8kS5wEwjqPOsYOOYEeBNo2wik/g+SdAai+Er3kQuhh/VAp xKRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ndx32WBmfBxuvJH6NgXVPP6Qai1KeFznS/MWmU68F2k=; b=focbI5iFxT7KTd8M1SMmUlCTanBtSFLBXEC5u03dAaBJtx1VB8G9vUM2zYsikM1MEt LwQiMrTYPpzp9Qfafkb7pWE+1bcfK0MTRRGGpKCKfA66jRu2UDGDvhS8JEBHxWkgxZz4 FuGhfbGmxLAk577ZDRz6QGyXb8N9yqHLF45f/Mra3i/L/xgln3Pi0y3v3DuEpc9Y2r+v kRuE/+0+fLBhPtOZT+1/xc3OkRW1NY7/UXw70l/Qt9TSu4nHcQnhkYHPmNP3tIbBI+vW hyANFzE6c9Czcv7AiFFDKr9sFWtPQhNBPkQ4QFmFkSfkkpfrj3LLOqrTrjHInkNwVaEJ xvag== X-Gm-Message-State: AOAM531BLrJkCuyQy48dm1FjRdbfyOWpZL6U6qSPskq2bhY7kHjvoUyM bIoQcTQSo3e5tW02bsw5Jg2EQ3qzKlym+sodw4y77Q== X-Google-Smtp-Source: ABdhPJy5alfRTJ16ow1R2qoghwtdNe1YLO1P7U2E+EplB8YB4Kg4kWeP+53DYGC1dkaYhZktOY9T6zkHogbJiFNWhcI= X-Received: by 2002:a7b:c057:0:b0:37b:ebad:c9c8 with SMTP id u23-20020a7bc057000000b0037bebadc9c8mr8419395wmc.61.1646845453376; Wed, 09 Mar 2022 09:04:13 -0800 (PST) MIME-Version: 1.0 References: <20220307184935.1704614-1-kaleshsingh@google.com> <20220307184935.1704614-2-kaleshsingh@google.com> In-Reply-To: From: Kalesh Singh Date: Wed, 9 Mar 2022 09:04:01 -0800 Message-ID: Subject: Re: [PATCH v5 1/8] KVM: arm64: Introduce hyp_alloc_private_va_range() To: Quentin Perret 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 Wed, Mar 9, 2022 at 8:50 AM Quentin Perret wrote: > > 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. Thanks for clarifying Quentin. That sounds good to me. - Kalesh > > 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 E9BF1C433EF for ; Wed, 9 Mar 2022 17:09:21 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=B2VZvHkVIkknQCnyE/QX9bMdXq03C4nMeuVuCr+nmJM=; b=BoLMDCkKAtnjqu 80jJwTTFl6kYGYnL0s9ymNG8Iv56Ng87nxaXu4BgBm64/tdBprTRGrI9LtJ3k9y7tMt9v36hwiTAS g2QIh3XAxVatLa3zg7+kWkUagGmi5YTIIGpIvPxCp7jMNHSRYtnTSjTrRwTQxnUMxFmyX4X9VSrj5 HRv5TVZfgLfS9xP2yvdxHYy/W66SUdPdCWe6tmlIwao8wgmUlcXbzZaCBEmbNWptrpcrkBmrcG+i0 dTjKNZMyF/Za5b+vMQSRlNFqIX0nY4XuBbtxhVxvJVLkP55NyvhIqL51RkmXK8AsXji4lh2uMUVlG F4PD7sf/F/flMT68RWkA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRzmr-009hMU-Ns; Wed, 09 Mar 2022 17:07:45 +0000 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRzk6-009fuA-U6 for linux-arm-kernel@lists.infradead.org; Wed, 09 Mar 2022 17:04:56 +0000 Received: by mail-wm1-x335.google.com with SMTP id n33-20020a05600c3ba100b003832caf7f3aso3268695wms.0 for ; Wed, 09 Mar 2022 09:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ndx32WBmfBxuvJH6NgXVPP6Qai1KeFznS/MWmU68F2k=; b=YQjVRwGsmDyttSMWRArNfLF0dqeQKY8E/07xyYcuzGr0kpyfDmH8G4dbdGdwdlBwnP zX1OtOneZOfWA5I7yR+egmuSJ2jHhH7Ut7NmOVk1XPYZi0TADjvFf5B5DFIvdUkNY62P +cvUl3a7OfQRD0oBDWHHEUNpZ7y2RxB1g2F8aRdKdvN5tt4jdIZjz2wzUoM1Xdj+uEwz 4YWWV1fNTpxtUqI9nbSpNzW55JCP6aUHS8hIbhGRLCdSUpYypgBjKrYzBB4AnrJV5Wj8 Cxpn/g7Z6EZckp3ywXFFKd8kS5wEwjqPOsYOOYEeBNo2wik/g+SdAai+Er3kQuhh/VAp xKRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ndx32WBmfBxuvJH6NgXVPP6Qai1KeFznS/MWmU68F2k=; b=cDRWXW1jjASWOFoJECcSRZBflpNO+OgHtE8R9yQz0ZSe/1kgtZACJkjQXYQMKQ6xhN StRabWcimlKuRqb23GdacBniYnwSHk1LUlcUWkEa29O4vhXOvRvh3LFoyKGkL3kOqqCF 4tfcsCiZ3z5ja16a5yMdYI4bRr/IjTpn+SMs0Sl7qIfRYQ6wIh/qBhyd932Oc5XIN9DZ oOcdQU+QDhqqEsj5RxPvTyKDHepNDzglzvdlvEdB54cRmQbHR+ybPOySvEksxsd86XaF M6Q74obhwewQMa5WjgoQ0mnCrGN6k/ioO7Wf6mWRJpsldYDf6Fb63TySyTfLvGqZpKfn Ohsg== X-Gm-Message-State: AOAM533+TTK8VVSp7v54D1wSlkO7quVoDMCpBQQALBp4VVncx6ReFJVM NmfLh+Av01wgVHbSsOi7mjXSx1BivmsEY+oaGLCoMQ== X-Google-Smtp-Source: ABdhPJy5alfRTJ16ow1R2qoghwtdNe1YLO1P7U2E+EplB8YB4Kg4kWeP+53DYGC1dkaYhZktOY9T6zkHogbJiFNWhcI= X-Received: by 2002:a7b:c057:0:b0:37b:ebad:c9c8 with SMTP id u23-20020a7bc057000000b0037bebadc9c8mr8419395wmc.61.1646845453376; Wed, 09 Mar 2022 09:04:13 -0800 (PST) MIME-Version: 1.0 References: <20220307184935.1704614-1-kaleshsingh@google.com> <20220307184935.1704614-2-kaleshsingh@google.com> In-Reply-To: From: Kalesh Singh Date: Wed, 9 Mar 2022 09:04:01 -0800 Message-ID: Subject: Re: [PATCH v5 1/8] KVM: arm64: Introduce hyp_alloc_private_va_range() To: Quentin Perret 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220309_090455_018721_66947923 X-CRM114-Status: GOOD ( 23.14 ) 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 Wed, Mar 9, 2022 at 8:50 AM Quentin Perret wrote: > > 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. Thanks for clarifying Quentin. That sounds good to me. - Kalesh > > 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 F0C88C433EF for ; Wed, 9 Mar 2022 17:10:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236887AbiCIRLU (ORCPT ); Wed, 9 Mar 2022 12:11:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44492 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236634AbiCIRLA (ORCPT ); Wed, 9 Mar 2022 12:11:00 -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 F3B212DFA for ; Wed, 9 Mar 2022 09:04:14 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id k8-20020a05600c1c8800b003899c7ac55dso2996957wms.1 for ; Wed, 09 Mar 2022 09:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ndx32WBmfBxuvJH6NgXVPP6Qai1KeFznS/MWmU68F2k=; b=YQjVRwGsmDyttSMWRArNfLF0dqeQKY8E/07xyYcuzGr0kpyfDmH8G4dbdGdwdlBwnP zX1OtOneZOfWA5I7yR+egmuSJ2jHhH7Ut7NmOVk1XPYZi0TADjvFf5B5DFIvdUkNY62P +cvUl3a7OfQRD0oBDWHHEUNpZ7y2RxB1g2F8aRdKdvN5tt4jdIZjz2wzUoM1Xdj+uEwz 4YWWV1fNTpxtUqI9nbSpNzW55JCP6aUHS8hIbhGRLCdSUpYypgBjKrYzBB4AnrJV5Wj8 Cxpn/g7Z6EZckp3ywXFFKd8kS5wEwjqPOsYOOYEeBNo2wik/g+SdAai+Er3kQuhh/VAp xKRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ndx32WBmfBxuvJH6NgXVPP6Qai1KeFznS/MWmU68F2k=; b=6Bk+ccegWlQCINtBFIEKQzIgyhSauZlsTN30QNnu9d+7LGuzI36dI0/USLWH21wJKN bRaJQf4h77Jl20NRW8OY+Xc04gq69RH+XZw5GuCTzONqwcG0mJf7sGLOvM35joi7HvFB iTlBUYFe7JeoS1l/JoEPhe97knQvilrSula6uKHRIuAopxrLEpAyUulHyJhCP+f9t4ur 7nQQDH2CeFEUk4mKZ4HjosNpGzoQTDXVLuvX1tV5v66cOaoEd9yGFEOgK0UfT9xGjBKf 1ziiiFWco7wkL98TNsd1u1KUwj7fg1zyEXi0Wp5AXiLjGUl0aKe0WRm+VYY0etrL/tHD VI5Q== X-Gm-Message-State: AOAM532nQFu5EoXUgas/KMnlGcGhFciEqyrKgyojunQk8rfO5VN1fByl dNvaiD6PLkN1gdRtXlUHTjwTHUKPpZUiMhokygWStA== X-Google-Smtp-Source: ABdhPJy5alfRTJ16ow1R2qoghwtdNe1YLO1P7U2E+EplB8YB4Kg4kWeP+53DYGC1dkaYhZktOY9T6zkHogbJiFNWhcI= X-Received: by 2002:a7b:c057:0:b0:37b:ebad:c9c8 with SMTP id u23-20020a7bc057000000b0037bebadc9c8mr8419395wmc.61.1646845453376; Wed, 09 Mar 2022 09:04:13 -0800 (PST) MIME-Version: 1.0 References: <20220307184935.1704614-1-kaleshsingh@google.com> <20220307184935.1704614-2-kaleshsingh@google.com> In-Reply-To: From: Kalesh Singh Date: Wed, 9 Mar 2022 09:04:01 -0800 Message-ID: Subject: Re: [PATCH v5 1/8] KVM: arm64: Introduce hyp_alloc_private_va_range() To: Quentin Perret 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 9, 2022 at 8:50 AM Quentin Perret wrote: > > 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. Thanks for clarifying Quentin. That sounds good to me. - Kalesh > > Cheers, > Quentin