From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E1F92346E70 for ; Sat, 9 May 2026 23:34:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778369688; cv=none; b=aljBqy46NpIzFwrdbXj1OA4GqzU1E3ySc7VNfslr2Oa4S7fUQ8r1ykXgLKwHjgZyDgHVT1onHATV4nv7N7qqFquPB20MV6Cff5EwiT+liyOLOkK9ZP0lbFmhuWxl0nsAa0A1HDJO563ZE1WLgLDFtho4NE/OSExFwynmtgwPVYk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778369688; c=relaxed/simple; bh=viE2tZT/M+fmeTU3fRuSrMwCvMP+jn8S3W++VN5Bl0Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tjRBj1RAthrRbmOjfON7UmzzTChT68IQRGmEv9FfEreMpyc43eaxN+qhhoa+TMOGphgo6ptgjxSp5uiF/ZahEEwmq/j5K3qa78HIjTU6cJ8gJMewG03QX1a54US968xX3CPqo0qkVsQKXeSxFCoyiR5KBWmjk8uoO4nOkARDgk0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=Cao+Aus4; arc=none smtp.client-ip=209.85.160.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="Cao+Aus4" Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-514ae601df2so1331441cf.0 for ; Sat, 09 May 2026 16:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1778369686; x=1778974486; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=t6tLt4US09DyLso/mhdji9Hp8lkbi3csRWs2bmEy9sU=; b=Cao+Aus4yj4QVJ1LqWvr+dqgsMBjjRlV3HSiIDuBXqddbwqy4jDpLNkZmB87gxbYRt mJO01e6RC/TJzbAnN2tQxbqWCEMpkNh6BoQKpSniyuH/2H0fZF+wD7ntRu+BgmZmczk3 v2eVRfzZ3gJJ3buJpPWGT3EiEA0L42fbYos8aSTY/my6Ih4UzbX8hOIwJTKVNuT6dlrF sFEbpO4jLAV/6R63gaSKqSmoO+p7Url7Dx80vGsqI1Fn9MlNzKUAYf51vVT7oNuQmHvc hMWJ0+B/76MrzE5xCmyDsgySW8PpxeYlEOavWg2p62HlMNzUeP/JEY1sG0/1EEtMSCqu u16w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778369686; x=1778974486; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=t6tLt4US09DyLso/mhdji9Hp8lkbi3csRWs2bmEy9sU=; b=aMh9m8/EP5CST1CGa7VOfGSa8tT//t+gqopoKd1z/2UOD1fIVnNZl9symDjpUMmvVh qjXPDkCwy8XGQUq0gitVRdeaj43/VRI8/7uCRMu4W2HIDKKwR3G0ShId4hZKYZ6FJ3rD zoR0TlZ+WowdkD+Mnz9M5AApa0Ppp7Uf5Zt9kbbL5e0QrJLGb5/xKYyrgBH/nNHov0Zv hAl5Y2pD29ThfqM5w3Lh1LMtnh3XL4/e2V/GubgttOKkufvT2R8dfUbY3KVMLQ7glWCm FMskk+MR9ZXfcHopif+c4HzuQHkTqmilXJsiGV8xq4xNd0ARKGqM7lBltCB8QlmljGS/ /UjA== X-Forwarded-Encrypted: i=1; AFNElJ98kVKGEYzzy7V7McYIGXbmbKcS9CsClftckGR2NR+3TeMD4WdE2RBANOkAvEYEW+I0dl8seHDnHAUDNKY=@vger.kernel.org X-Gm-Message-State: AOJu0YzYgNE6dvCuww6vZRzHu5pXRAX5p+3173Rl/A+1CoFTcNYpRQMZ H2Kjqff4IaXF4a5JR8pkKpuwdaBaPuafjNvS6Zjn5rHabBoelsBIXlv5v6nNlp0UsTCrJ03pbXO 4Khn6xEM= X-Gm-Gg: Acq92OG93LlB5zBFTWux0ZNEZlFBWQfzskmZAx85BydvJSGYRtOT8JxpXrqTN4kEsx8 9gShUULdIBaPswDeJKyUx+pI9e3LP5yy4Fl74W6SBmmtjZ7Mp+3+gWMQ19K3y4m2GRLu+4I2YD5 E2OvFeuO9/AhAsSVhi6ZR3uNxiTO+q7x39ByV8v81YOxoxEIUWJnfryKOJRNuwiuKuesvi53pgw Dt8S99LAE0gXmI+JbrZU5D4v6u8JnaincPdcMyrbix5MAZHmPwo+jgBCy0Q8GDmqnXaz26Qsqa+ mhJwdQ5kPHHORTepGWz/MNC8BaEuczsytwqb3oAaiaBWK5OlQvT9raXDyiDyyQuAARc6NAsKOOZ rBOJARyFs67SZG/Wt3Y88JTxkua8mRE55i8ycMAZJ2y0g0bZTYI/L+LqiZogTdQaR0+ZXmADjco pFfGooGJPGMJSOwsbi1JCjX4YrK5vhgZek3pulqT0fYiKeMI3rGZ+Z3GJO/vmfgK3qj5D4IYVdt 8Es256BIGxgN8IQ X-Received: by 2002:a05:622a:5a9b:b0:50e:6139:492b with SMTP id d75a77b69052e-51461c3620dmr247096161cf.23.1778369685834; Sat, 09 May 2026 16:34:45 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5148e7e3d90sm51028881cf.20.2026.05.09.16.34.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 May 2026 16:34:44 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wLrBz-00000002ONN-38VG; Sat, 09 May 2026 20:34:43 -0300 Date: Sat, 9 May 2026 20:34:43 -0300 From: Jason Gunthorpe To: Mostafa Saleh Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, iommu@lists.linux.dev, catalin.marinas@arm.com, will@kernel.org, maz@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, joro@8bytes.org, jean-philippe@linaro.org, mark.rutland@arm.com, qperret@google.com, tabba@google.com, vdonnefort@google.com, sebastianene@google.com, keirf@google.com Subject: Re: [PATCH v6 05/25] iommu/arm-smmu-v3: Move IDR parsing to common functions Message-ID: <20260509233443.GK9285@ziepe.ca> References: <20260501111928.259252-1-smostafa@google.com> <20260501111928.259252-6-smostafa@google.com> <20260501124716.GD6912@ziepe.ca> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, May 07, 2026 at 10:13:13AM +0000, Mostafa Saleh wrote: > > I was thinking more like > > > > #define arm_smmu arm_pkvm_smmu > > > > Before the pkvm compile of the shared code. > > Oh, so we rely on arm_pkvm_smmu and arm_smmu having the same field > names and types? Just for the shared code, yes. For instance this patch would require the features field be present in both, and then all you do is directly copy all the smmu->features logic into the shared file and that's it. > I don’t think that’s better for maintainability, I can look into it > if Robin and Will are OK with that. I think maintainability here means pkvm minimizes how much it changes the code of the main driver. Copying a bunch of functions into a shared .c file exactly as it is, then compiling the shared file with some #ifdef'ery at is going to be long term better than trying to mangle the whole thing to avoid using any of the core types and not directly share the code, IMHO. Like my tlbi point for instance, it is not a good idea to rip out a little bit of the invalidation logic then open code a pkvm version. Use the exact driver code. But to do this you need to pass an arm_smmu through to to the pkvm specific queue management functions. > > How does pkvm compilation work anyhow? Is it all rolled into a unique > > link, or do you have to worry about symbol conflicts with the main > > kernel? > > All pkvm symbols are prefixed with __kvm_nvhe_ in the main kernel. So automatically with objcopy or something like that during the build? Jason