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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 BADB4D5B15B for ; Sat, 13 Dec 2025 12:43:21 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2DD1A10EB23; Sat, 13 Dec 2025 12:41:06 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=permerror (0-bit key) header.d=gmail.com header.i=@gmail.com header.b="EbjDaLrt"; dkim-atps=neutral Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1575810E1E0 for ; Sun, 19 Oct 2025 11:57:33 +0000 (UTC) Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-46e6ba26c50so23219115e9.2 for ; Sun, 19 Oct 2025 04:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760875051; x=1761479851; darn=lists.freedesktop.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=CFyJz4TGbBiB8xKgL30elmXo6maKrPja2K5Egv8H5yA=; b=EbjDaLrt3MxyCEsZhNcftxXorWLKIhEuF3RhPlP2qFYrbQps9YvUflv8lANHOmF+oV NoeSw9peUOz5cX4U6dBPiAnoQwRS0HF76spwMkTIh5IHIiAF+ZssaHDuCxLHzkVxpbge MgBb7wmtDQWojH8dnPEl8Voq/AZ+ySbjFtAgoE2EBotyPvWQJzs3Bgb5bEJ1N/BYgrkB YPvkO3rWgWJRvLXgfTZXxJ3M6Z2SgvZ/gQROywFim788CqU8K2n3WrrUq1linRPvY/0k sdghJ5qMtPSmzBiKITnE1peN9owPfB1oVVAhH4CraKjqvxxVGbbc02DdEydy5/My8zT3 L6NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760875051; x=1761479851; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CFyJz4TGbBiB8xKgL30elmXo6maKrPja2K5Egv8H5yA=; b=is+ckt7bejgeDcHYBcFkgGMX9lvkQMBr2MvbAcF0IrSOolIOaDpDw5T0ExI12DMilA VlW5H1NawmamHRS9u1WRU6I5ei1IoxJ+Ho5g8aLigUekSXMhPkh+dOUr13ScpHoOSeEW J3tSwmhihlrbmK5u7joVLGWJfImqba0FgOjQN5QLF33HXh0muF/Bcw71H/X9paDvEIgn lgUMBwLClF2wQZ9Se4OocUSooz4KJHGk0xhjNkE/gXSn/I1S4SrS7zaifQzsNVt5fqER B7bXyOsbu0ydfeF8ZALcaMdNQ+FkzVwOTzWgLS1eSqE4Xm6xMNn3pmocyTDrYY45u5oT wpXw== X-Gm-Message-State: AOJu0Yy3fhLQHk/xVRUghSn/+j08Rx2GM87nQPh3lpQ+qNpDnlFW+oPO U0njoE5xMLmYzLphY0/rAhkZxMmdeeboUjaiILaIa1hzRgzjmJCM1Dvk X-Gm-Gg: ASbGncv1XmndElB5zipVtYNMghyXXeHIfuCwkMdDjZay8ctWD8XuGcq+5l35lPGoOA0 Oo5/GlTaJPfZe6Ei/v1NWBxTC9G+0+EDJgAVkqr4OHPLIqd7q9os/0UybcGmMExk/xhFLREkCZM Tjc64tvdi+bpO6JI9ZkzoTTJC3ytnfX7ucBCCC/xnXPO25XOMcGK8b0K7V7mfr+YIZiVhM8ebhc 0SvxZVfPlFYQkTFpnjUq8AAWOeo+oKmDQ73oNiplbKodBGWTc9R7SVaNWaA41vpX7zTttAQiHf8 evgtUsrdrJSrd2+zGgyr2w/ljDkxoqidEK1gx0A5vuibrOb9GvM0nMRODiCPIfk0OQDvgUbMwh3 kipLEMkPd5Q2zquwg6HxpC8biUej7FfUtyv5ooWbZYfZgLdveJ3kMtcnpBjk/clrwQU9SaLg6YV awfYbxNP9ixQ10uRDipycMGWY7jCOT9yH2cITHsGKrq1Tkrt52Y0pTJx5tlMBcgxUWlOE= X-Google-Smtp-Source: AGHT+IHvDD+ifAg+17oqux4wEgOfVHaOlLPFxtbGdrBBFjTGnfI9PU8wWphxIaLJLYGzyWFboM6Djg== X-Received: by 2002:a05:600c:548a:b0:471:669:e95d with SMTP id 5b1f17b1804b1-4711787dcc8mr62020415e9.12.1760875051305; Sun, 19 Oct 2025 04:57:31 -0700 (PDT) Received: from ?IPV6:2a01:e0a:acc:bb60:756b:64e3:20ef:1d08? ([2a01:e0a:acc:bb60:756b:64e3:20ef:1d08]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-471529598c9sm91035475e9.5.2025.10.19.04.57.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Oct 2025 04:57:30 -0700 (PDT) Message-ID: <72cfbe83-e587-441e-abfb-b50155a326ab@gmail.com> Date: Sun, 19 Oct 2025 13:57:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] nova-core: Solve mentions of `CoherentAllocation` improvements [COHA] To: Alexandre Courbot , Danilo Krummrich , David Airlie , Simona Vetter , Miguel Ojeda , Alex Gaynor Cc: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , rust-for-linux@vger.kernel.org References: <20251015194936.121586-1-delcastillodelarosadaniel@gmail.com> Content-Language: en-US From: Daniel del Castillo In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 13 Dec 2025 12:40:46 +0000 X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" Hi Alexandre, Thanks for your comments! On 10/17/25 03:36, Alexandre Courbot wrote: > On Thu Oct 16, 2025 at 4:49 AM JST, Daniel del Castillo wrote: >> This patch solves the existing mentions of COHA, a task >> in the Nova task list about improving the `CoherentAllocation` API. >> I confirmed by talking to Alexandre Courbot, that the reading/writing >> methods in `CoherentAllocation` can never be safe, so >> this patch doesn't actually change `CoherentAllocation`, but rather >> tries to solve the existing references to [COHA]. > > This mention of background discussions should be in the comment part of > your commit (below the `---`). Noted, will do for the next version of the patch. >> >> Signed-off-by: Daniel del Castillo >> --- >> drivers/gpu/nova-core/dma.rs | 20 ++--- >> drivers/gpu/nova-core/firmware/fwsec.rs | 104 ++++++++++-------------- >> 2 files changed, 50 insertions(+), 74 deletions(-) >> >> diff --git a/drivers/gpu/nova-core/dma.rs b/drivers/gpu/nova-core/dma.rs >> index 94f44bcfd748..639a99cf72c4 100644 >> --- a/drivers/gpu/nova-core/dma.rs >> +++ b/drivers/gpu/nova-core/dma.rs >> @@ -25,21 +25,11 @@ pub(crate) fn new(dev: &device::Device, len: usize) -> Result> } >> >> pub(crate) fn from_data(dev: &device::Device, data: &[u8]) -> Result { >> - Self::new(dev, data.len()).map(|mut dma_obj| { >> - // TODO[COHA]: replace with `CoherentAllocation::write()` once available. >> - // SAFETY: >> - // - `dma_obj`'s size is at least `data.len()`. >> - // - We have just created this object and there is no other user at this stage. >> - unsafe { >> - core::ptr::copy_nonoverlapping( >> - data.as_ptr(), >> - dma_obj.dma.start_ptr_mut(), >> - data.len(), >> - ); >> - } >> - >> - dma_obj >> - }) >> + let mut dma_obj = Self::new(dev, data.len())?; >> + // SAFETY: We have just created this object and there is no other user at this stage. >> + unsafe { dma_obj.write(data, 0)? }; >> + >> + Ok(dma_obj) > > Can you preserve the use of `map`? This removes the need for the > temporary variable. > Sure.> >> /// The FWSEC microcode, extracted from the BIOS and to be run on the GSP falcon. >> @@ -260,32 +245,38 @@ fn new_fwsec(dev: &Device, bios: &Vbios, cmd: FwsecCommand) -> Re >> >> // Find the DMEM mapper section in the firmware. >> for i in 0..hdr.entry_count as usize { >> - let app: &FalconAppifV1 = >> // SAFETY: we have exclusive access to `dma_object`. >> - unsafe { >> + let app: &FalconAppifV1 = unsafe { >> transmute( >> &dma_object, >> - hdr_offset + hdr.header_size as usize + i * hdr.entry_size as usize >> + hdr_offset + hdr.header_size as usize + i * hdr.entry_size as usize, >> ) >> }?; >> >> if app.id != NVFW_FALCON_APPIF_ID_DMEMMAPPER { >> continue; >> } >> + let dmem_base = app.dmem_base; >> >> // SAFETY: we have exclusive access to `dma_object`. >> let dmem_mapper: &mut FalconAppifDmemmapperV3 = unsafe { >> - transmute_mut( >> - &mut dma_object, >> - (desc.imem_load_size + app.dmem_base) as usize, >> - ) >> + transmute_mut(&mut dma_object, (desc.imem_load_size + dmem_base) as usize) >> }?; >> >> + dmem_mapper.init_cmd = match cmd { >> + FwsecCommand::Frts { >> + frts_addr: _, >> + frts_size: _, > > Can the `{ .. }` syntax be used here? > Yes! I didn't remember that syntax. >> + } => NVFW_FALCON_APPIF_DMEMMAPPER_CMD_FRTS, >> + FwsecCommand::Sb => NVFW_FALCON_APPIF_DMEMMAPPER_CMD_SB, >> + }; >> + let cmd_in_buffer_offset = dmem_mapper.cmd_in_buffer_offset; >> + >> // SAFETY: we have exclusive access to `dma_object`. >> let frts_cmd: &mut FrtsCmd = unsafe { >> transmute_mut( >> &mut dma_object, >> - (desc.imem_load_size + dmem_mapper.cmd_in_buffer_offset) as usize, >> + (desc.imem_load_size + cmd_in_buffer_offset) as usize, >> ) >> }?; >> >> @@ -296,24 +287,19 @@ fn new_fwsec(dev: &Device, bios: &Vbios, cmd: FwsecCommand) -> Re >> size: 0, >> flags: 2, >> }; >> - >> - dmem_mapper.init_cmd = match cmd { >> - FwsecCommand::Frts { >> - frts_addr, >> - frts_size, >> - } => { >> - frts_cmd.frts_region = FrtsRegion { >> - ver: 1, >> - hdr: size_of::() as u32, >> - addr: (frts_addr >> 12) as u32, >> - size: (frts_size >> 12) as u32, >> - ftype: NVFW_FRTS_CMD_REGION_TYPE_FB, >> - }; >> - >> - NVFW_FALCON_APPIF_DMEMMAPPER_CMD_FRTS >> - } >> - FwsecCommand::Sb => NVFW_FALCON_APPIF_DMEMMAPPER_CMD_SB, >> - }; >> + if let FwsecCommand::Frts { >> + frts_addr, >> + frts_size, >> + } = cmd >> + { >> + frts_cmd.frts_region = FrtsRegion { >> + ver: 1, >> + hdr: size_of::() as u32, >> + addr: (frts_addr >> 12) as u32, >> + size: (frts_size >> 12) as u32, >> + ftype: NVFW_FRTS_CMD_REGION_TYPE_FB, >> + }; >> + } > > I liked that the original code updated both `init_cmd` and `frts_region` > in the same match block. I understand it might be difficult to preserve > due to the borrowing rules, but can you try to preserve it if that's > possible at all? I agree it was nicer. I tried to preserve it, but I don't see a way to do it cleanly, as I can't keep both mutable references at the same time. What I could do is only check `cmd` once, set `init_cmd` and store an `Option` that I will later use to set `frts_region` if it's not `None`. Let me know if you prefer that. Cheers, Daniel