From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.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 4135F3F7A98 for ; Mon, 18 May 2026 11:52:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779105166; cv=none; b=GBz4a2OTti4CzJj/AS0Kznhp5rL8/RZq2hdSFYqBzBEJmYyoMosYgOMApEnymw3u1IJXpxakRSsZU59JpU8/4fMiLk6zDRFkhdoqnWYkfOwazuGmLkBQLSjCZJM6LEc59afPU9pS1OAfBouMK6P/+3QvmI31cTKldVyG2ZdE9s8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779105166; c=relaxed/simple; bh=TSOB6Vbocoq6beDn4FEEEYUinkclZ6btSniPfWEeNtQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DH+Zk+r3IMrOyqMUySCAbH8csu5eHAYpk6JlhOY4vMJwyTBi7bEp5qjmV+IhBBDhE47K/u1bWBLL4OfH4tCkC/Yy49LfNVOMk3dmVupYZJlUeFQrNhuHUHSKvj8X07v3OZbZ09nh/lthzLnRJFWRBEEShsdb31XNFnhWFUAxS00= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=mexQEhp5; arc=none smtp.client-ip=209.85.214.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="mexQEhp5" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-2ba180a022dso1035ad.1 for ; Mon, 18 May 2026 04:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779105165; x=1779709965; 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=4yLlmjF/IblV5lnEQi8qY+GyBL0qWeQ1d8R8yUsdmKQ=; b=mexQEhp5zJyVBJS1+G6zq+V7pCfuWuiIlEDyRWUqXcHkGaZGqjS2jTLXqe7z53/WA7 JNAvkYdCLZg7Lk50mvQq6p+tzuTKzPNSp6RewVGHGoN6+dGWM0aQnSUF9R7+DJQ8J1jH 4ibbJRmeJCmzYoT2Fw5sBjLp88xKILoVZYPQavA8h6NNItLYUaWa/6i3bwSfMbaPWey7 m0WsTkdl4wefCV7331m8k9mZSmuzmO8V/BpJEZVCFLnEOU2yA8EXFyI6nXfMPJ0n/BlH r12oKzeQGcFeJmKayY+4qEE4U9bpwOyrs4m1hq1Wjfx2qc46jiuljl1Hfi2MG4hUReVz mF5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779105165; x=1779709965; 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=4yLlmjF/IblV5lnEQi8qY+GyBL0qWeQ1d8R8yUsdmKQ=; b=cXXxOUS8sB9hMAQRRxDOmeMIzPUEXXxCgI5rf3s0V+QUm4WDnYDzfEYKt05M2CW4Vd iB9MBkMIbmwo7WS00vjhGiQzMfkBWz31L8gfwkndT7CAErxsLv+pmsBda8UwFSbElDRD jHPUJmbtWAFB6SpXYqbG4J8l/LOs0igpYJ9VoQ66tRYdd3/Ebs2CccNVcp++xL5TN9vv z8p/T2Ku5nJaJwAPowHq4vHB3D9EHixGu3Cg3Mp407FrTEqlFjqx3M/6p7hcpKpJT7k5 9Bjt3m2jgy7v45soTB/ALe9GZ3A8TnCoO/WvJZ7aD6CBxIsANiPru9rM1YjMeRQvqdTT 0y9A== X-Forwarded-Encrypted: i=1; AFNElJ/EfniSzDHml2sTzwQDCWVnrKtMShKaMH359xC5tlq9huw5usJ3zY/C0j5i2TUz7Zyr0jRtGihnQuyrkFs=@vger.kernel.org X-Gm-Message-State: AOJu0YxqWtbSB1rsBfg05p5Mlxbk4O84vnuqZIT5ukr6fBV3wAV4MUhv CDe70sraM82H4U0EOfatxkW6ZvWD1npgEeKnvoR8MheRUKUMQIYBCxBOnHvTpH/W5w== X-Gm-Gg: Acq92OF9LVzU84tpwmLJoUDERpg5Hn/WmPAupYpQz1uFd0p0szj1UlD7z1LkeTynnFT wQrro9jCtIMOGHIn8Xz9wLCBjwhGk+HnP7M4jb5sIiRes7NsNh9IigtyM5ZzXnkWiaXsFgUuXN5 jrSXpw810hUiraX4PpyUUusUY67JOL0sVS2ftPC0KVN372is94OpV+1a6iYbwDXnE5WSKFe6gOC uV/XORjvKV5qzZquEWo3cOtvziSpOg3sngjP9nw4XTBrx2RPMv4InC/XoBlJoLnVM11PECAR6tG FCYNSZFqLHl0gxyA/ZCPTirDSbfNZaNzMBTJYY/ClWurTEMtvfEwRKBtGn9i8ZSNU07Rqg0SGAx aFGIQz52trtdtC97IzeS8Aa3Df4lYr4WvpiP8orSZKtbJTKZSuuU/nq8s2mOIKV4g+TdaGFy+N/ 0HfGBn+sMdZtjyDcnfsiibAy9CzWcwATnzixyrFyM8nQNXvfFX/7XIMCizS4RLMZkdq9+8 X-Received: by 2002:a17:903:1b67:b0:2bd:6dad:7cca with SMTP id d9443c01a7336-2bdb0416740mr2770155ad.22.1779105163837; Mon, 18 May 2026 04:52:43 -0700 (PDT) Received: from google.com (44.234.124.34.bc.googleusercontent.com. [34.124.234.44]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-83f19c5ceb3sm14293391b3a.34.2026.05.18.04.52.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 04:52:43 -0700 (PDT) Date: Mon, 18 May 2026 11:52:34 +0000 From: Pranjal Shrivastava To: David Matlack Cc: Samiullah Khawaja , David Woodhouse , Lu Baolu , Joerg Roedel , Will Deacon , Jason Gunthorpe , Robin Murphy , Kevin Tian , Alex Williamson , Shuah Khan , iommu@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Saeed Mahameed , Adithya Jayachandran , Parav Pandit , Leon Romanovsky , William Tu , Pratyush Yadav , Pasha Tatashin , Andrew Morton , Chris Li , Vipin Sharma , YiFei Zhu Subject: Re: [PATCH v2 02/16] iommu: Implement IOMMU Live update FLB callbacks Message-ID: References: <20260427175633.1978233-1-skhawaja@google.com> <20260427175633.1978233-3-skhawaja@google.com> 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: On Fri, May 01, 2026 at 09:45:19PM +0000, David Matlack wrote: [...] > > + > > +/** > > + * struct iommu_hdr_ser - Common header for all serialized IOMMU objects > > + * @ref_count: Reference count for the object > > + * @deleted: Flag indicating if the object is deleted > > + * @incoming: Flag indicating if the object was preserved in previous kernel > > + */ > > +struct iommu_hdr_ser { > > + u32 ref_count; > > + u32 deleted:1; > > + u32 incoming:1; > > Are C bitfields safe to use in Live Update ABI? > AFAIU, they aren't. The C standard does not dictate how bitfields are packed into their underlying types (e.g., whether they are packed MSB to LSB or vice-versa), making them highly dependent on the compiler and arch endianness. I agree that we cannot rely on bitfields. Let's convert this to something like u32 flags; field and define explicit bitmasks. > > +} __packed; > > > +/** > > + * struct iommu_flb_obj - FLB object allocated in current kernel pointing to > > + * preserved state in FLB > > + * @lock: Mutex protecting the object > > + * @ser: Pointer to the serialized state in FLB > > + * @curr_iommu_array: Pointer to the current array of IOMMU instances > > + * @curr_domain_array: Pointer to the current array of domains > > + * @curr_device_array: Pointer to the current array of devices > > + */ > > +struct iommu_flb_obj { > > + /* @lock: Protects the serialized objects during concurrent preservation */ > > + struct mutex lock; > > + struct iommu_flb_ser *ser; > > + > > + struct iommu_hw_array_ser *curr_iommu_array; > > + struct iommu_domain_array_ser *curr_domain_array; > > + struct iommu_device_array_ser *curr_device_array; > > +} __packed; > > This struct is not ABI so it should not be __packed nor defined in this > file. I haven't read the whole series yet but this definition can > probably go in drivers/iommu/liveupdate.c. +1. Thanks, Praan