From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) (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 6E1923093A6 for ; Mon, 11 May 2026 14:30:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778509855; cv=none; b=ALGj6+ZqqQnVM46SgrFAb4Fz/+VUIqsbWFgEPB/BGUe5yH28G4/AfCyfOMJEggf286If29jXnO3e3Masn/yXi08HizI7iQ6KIRUkBsoXQxegog2OO4pxmJrZLnlIBFAQmangoBbJduNNq6X0/DpdGxqmybnaQ72Tc9sqWxPSdeg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778509855; c=relaxed/simple; bh=KyLuFEE+coaf/jJEo/cblEGq/QqRcgAQPejr03h+6d4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KEphVZ0nP7Q3pKq3qJ4IkM660rMH+87XuBCewwXS6j2803KQL9W+sYnCo/5Smb1sf2AXdKfosjhMTJxrKOXuzyBMC5CXGOE2sPR9w6BPRyDfZ4HRFF5wVyVFjSOFtpo0Z22SoQgSf6tES9UIUwlDrivD0a6ev4dqCY9gNeEBtyY= 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=QPPzkOuj; arc=none smtp.client-ip=209.85.160.170 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="QPPzkOuj" Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-50e63771eb0so41088761cf.3 for ; Mon, 11 May 2026 07:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1778509853; x=1779114653; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=1t4Q3YbgMx/6e1k8a1sHgBJ6iv/rwR+3bFc9xbIXC10=; b=QPPzkOujCexMffu0aw672WiYO8/okgNaKWzPJUkOn5NA2lE5axmoJ5wleVzlrgNCtV vChGT+//98FfwRKUv6lhB6qyF3R9mSquRHVAgbFKJtV8c3OOtwkfqHcio7p/LRhk4cmU NpRp0DckMgquaFcAREMiprn7T8BcTXf+qYBBYQ2BIOF4X3a47fLCBAKh3R0XOmP+mHHy Cp4RrQbjCPksCRkJUFfuqdaymMIY5oqCyCyJrZ1gZV/pvcY5Rdxc1fd+dcpMeozx3PJ6 wfScV1toQfNSqWqGKz1wi9oVqe+wJCELZCyiJB1lThomfxWPZIoStz4B/VCXiHvrh4yV rKQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778509853; x=1779114653; h=in-reply-to: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=1t4Q3YbgMx/6e1k8a1sHgBJ6iv/rwR+3bFc9xbIXC10=; b=YNZmN9ty9wDBpKMe7sBD8s8qe7lZrJAIUJYED2y4WjpVl+e1NlDQ8Boy0hSxyR5C40 0qmhmqAVHpDrWbbUy64LDEXcSOADLFvc68ZnP7HxxZhSByjvy2FWYBBoaFZKejsEJ0Ih c0yl3jJSFlHEn8lHur1RjBH9DaKXzdm1ct9C2TWjwgrtc2EQFEEYDfPYG1Q+zFOpKiJj DF5B7udDIYRAZI7AWoT9c4JcdCTnJYKaEYrcqZUuKQ46dhY0EX+eOoB9SbA8FlG/pqMA P5v0Fq+w0lbKGs7RBe4FBGDZF1MWd/GHduKbhriMyoJK2HD44GalSXOSk1XDHxY7dgCv iGmA== X-Forwarded-Encrypted: i=1; AFNElJ8m6dp8ShnG619NTrICu65+CIZkLphy6gI5/9H1R1HldPBoFxT/HL5KAvqX4PlAVTxDYiIHDSp1smbklP0=@vger.kernel.org X-Gm-Message-State: AOJu0YxxhwBUjYoI/eSDlEm9gZ3BN79x6TZFG3spDINPHPJDhQ3k/ywU 36USrZhmcy7HwDUz3fgEKhueqlmsEJs3j5d6EPxfIyRU+8S282+hdtfwIE4opOHNSAU= X-Gm-Gg: Acq92OErId/v9xQ8C8IoHDm6ErhLca0kjVGXbIzW81Wbw/jtwfKEoz+B0PWORd2tz1p NBbNqRVRf5C/86zZQZAbpxCwtvZhrdhEHCi2ZIecVOzosxrgoI4qNafCuudn26uLltBdfEsBJbo qmQK1SD/KjlV8U2ufIrKUkK4oxeMab5rTATqv0OnIvWCMeaV9ZG1yKESGLLmKy05WBDeVmssc0U +Kz3DzGw4coNgegU26Zcn1c4MgaONkRjcK50Bwjkzmcevrt8XLx9jWZdCpRtnnlcGVtWO8oCVlt DDi6YCr3Zf9YfcT9+c6oemFwsdtDajFpZ/4wLYL0JuU8jNOJBFK3N8Na56MT/05LKJmXVlT35ze eBqMW022FFz79KDseByCtxD83MBjt4XUdMgVGoKLX/5keHpQ04XRkfRVBMayyIFXISPGw0nSLQM BY/vACsuDWUlmR3uHuf4VcUNs6gOn3TYuF05hwCw0lZSAa90+UEm7TZ1YQQzSocAWnOzbuQXP3y MhzDA== X-Received: by 2002:a05:622a:d5:b0:50d:2a76:43c5 with SMTP id d75a77b69052e-514619de7e5mr335362441cf.2.1778509850538; Mon, 11 May 2026 07:30:50 -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-5148e83aa2bsm90525421cf.28.2026.05.11.07.30.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2026 07:30:49 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wMRej-00000004oIk-12xC; Mon, 11 May 2026 11:30:49 -0300 Date: Mon, 11 May 2026 11:30:49 -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: <20260511143049.GR9285@ziepe.ca> References: <20260501111928.259252-1-smostafa@google.com> <20260501111928.259252-6-smostafa@google.com> <20260501124716.GD6912@ziepe.ca> <20260509233443.GK9285@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=us-ascii Content-Disposition: inline In-Reply-To: > > 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. > > > > There isn't #ifdef'ery at the moment, that's what I was trying to > avoid by introducing shared code. Yeah, I think that may be a bad direction. Ultimately it feels like it will be more burden to maintain this careful split, while some small list of carefully selected #defines will let you reuse alot more with no code changes and I think that is ultimately going to be better. > What concerns me is how fragile that is, any change in the main struct > can easily break the hypervisor, unlike if we have a clear shared code > and defined API that is used by 2 entities. > I will think more about this before v7 and see how intrusive it is. IMHO so long as it is easy to include pkvm in the compilation I see no issue with build testing the pkvm driver when working on smmuv3 driver. So I'm not worried about this, any breaks will be compile breaks and can be delt with. What I'd like is to minimize logic changes and maximimize re-use so you don't have to make bad re-implementations. Like pkvm shouldn't be building a weaker tlbi, it shouldn't have different logic for errata and FEAT, it shouldn't be doing STE changes without the hitless logic, etc, etc. All these things are easier to solve with greater direct code re-use.. Thus I feel the trade of off 'use the code with no changed via #define' is better than 'try to carefully cut away and avoid #define' Jason