From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 195303D6CD6 for ; Mon, 8 Jun 2026 14:51:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780930277; cv=none; b=WVDO+aL0qEi46+yFTWa846jQJYbpO9Qe4SnypTPHR1Y38VN2lhVAOYqf1S83eK+Wg0D+JgzCINxJLCsi14CIXM2YTdsHYSevR/+yvlC2sJqIInQ249+jTiBiszIZVXxMIhhc+oEbpM25FjFzWiDSMRizCY7T9YlMg2G5P48/rhM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780930277; c=relaxed/simple; bh=La7g/GyA5jGa6VE7XI8C/nWm5pFkkzQfJczImT5HajM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ogdyc36p3HIEBETk9qtVUZwltQd/hi/DwHVbzXrwM0/0SEpPFCF2S8nDzWBVk2g1pz6MAQV4JvAxjrS7u/6SOvEUPmRNG3VQ1o2W4frN3ceCbzspGWxbFbpSIMfw15yzhaMprGcW3Q7SJ13Cs1hy34EWHtXDHgrOGry14j69i+0= 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=s61smTmJ; arc=none smtp.client-ip=209.85.128.45 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="s61smTmJ" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-490bd64ca95so199525e9.0 for ; Mon, 08 Jun 2026 07:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1780930273; x=1781535073; 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=0Rbn7wD4zfL1rg1LaDWefzl7m3050O9wzsCOn/zNYoU=; b=s61smTmJUkGBIlhhNxrhmPo8TdAaVWd0gemroF8XSC67PL8Jyg16p0QmWeoWPNw73T WaU1z8B6iq4LuTG8BWbhGh9IlxfIuIBDnCA4ElhUe0u0uJBQR9eLC6elk24YccprGLV3 nSGcZvfSZiFoODpyTxqYTS+cey33O/JOoFpe8Kyng8JDjSf3AistwLgPTiUzTsMjuU3T TzviRZraskpQ2ErdrjXina7+UMwKU34KpJQD8JUdCBb18cpRbfTE9cyGohcE7weL2Cgj 1kJAtPyZiNzk9uHD4FbrQDXcucjEl8wOcT6QeuErfiw02S/zGlKzG/7BpWzUzECbqz3d 9u9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780930273; x=1781535073; 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=0Rbn7wD4zfL1rg1LaDWefzl7m3050O9wzsCOn/zNYoU=; b=e+ZZGd5KqWH3ERBy9GFlledP22h304ghpJ7kUdQVU6SA90zwD9uoRZOZoklgMEF7jk Aeuwb80Kmuj2xqPRxdjNs1PzBUjqBcNA/OxkYhWenW7Uc8CBEhjMkSCXZZOoOwdCjaPM boGFYlqjeQtF4mYsTuFia5I2DKCMtPcea0+a0Liucmb9m4c80byqomE8MJnbqx12NdXG 9STL3Jpw7ZnsuAQ6TCMTdDPaxOzTQbW7H4DsHbXJ48civhmEuGkaDTjwpRN3mQflS83R VeIjl4pq9wRJE5wuJ/OFFISGOtI/Hp3mo7KVYGljWafRUKY+bWW2kj6pmudOv7U23p21 4z4Q== X-Forwarded-Encrypted: i=1; AFNElJ+ETynX2IXWY2rAlfYplN9cIlN9JjiXxU2Y77HHduvovSTL4sWLHSd/zPnkgBaQ/jO9n69kGvVR8G8/qes=@vger.kernel.org X-Gm-Message-State: AOJu0YwCPzVj9jrH2y0x2l5G4cHGxkQ6uLY2sWCzF/uVi+rrGo73W3vx v+XIyKuESF1nF2kIZaMkIEe+HXthTLuNbzTtGC7sbp6SsYLvbE5E9mMDG0hYtVFDvQ== X-Gm-Gg: Acq92OFEL8ACYmphuLmmAANIQHFUxAM87+NPuUa++zPfYAFSVFY89r3x83VJxVuuYey /iOuFQ5Yyi0yb7TNNImypmwoB2iXat/SOsttU1LmIAIJZSwPwd9erJwgP6nm8VOlrFTvEq+9Cal S8swzeo+EfujWoJIT5nPfHhwa9eJCtLZwHOOq7mnvA/lK4bkekC7W5DLKVwOIiZs2hHIG9405r/ aa5xkIrgSiVj3TC14QHnGzolXf2pdWPzkLnKWF3d+mK8LW2Mp63sxt6+pDRMFBo707DmwgMjN+m dU/oDKlBCqFnz/q7Wmixbr6+mA8f/6j0YI3TOSBq+Xl4pudT0cJZHNknZGHgYO2RGpZ8NDGgU6J KVXGivXfdgkiW8DPkpVMEKPjvSyFb5ExOAbT4aZw5pMV186DUYiO6v+Qe6i/saTgk2Gtj45YDOv zY/WR4Gs8ihRiwv2D0oYPcs0JOAShdmPu/TSeTrlZA0tlh+8GDuXD7c+AA9Qpr99oz5vNEuhLzd jTiTdhx X-Received: by 2002:a05:600c:4711:b0:490:c2b6:de6d with SMTP id 5b1f17b1804b1-490c2c9d9e4mr5232255e9.14.1780930273097; Mon, 08 Jun 2026 07:51:13 -0700 (PDT) Received: from google.com (143.11.148.146.bc.googleusercontent.com. [146.148.11.143]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f351d40sm52211734f8f.26.2026.06.08.07.51.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2026 07:51:12 -0700 (PDT) Date: Mon, 8 Jun 2026 14:51:08 +0000 From: Sebastian Ene To: Will Deacon Cc: Marc Zyngier , catalin.marinas@arm.com, oupton@kernel.org, joey.gouly@arm.com, korneld@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, android-kvm@google.com, mrigendra.chaubey@gmail.com, perlarsen@google.com, suzuki.poulose@arm.com, vdonnefort@google.com, yuzenghui@huawei.com, Sudeep Holla Subject: Re: [PATCH] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Message-ID: References: <20260501114447.2389222-2-sebastianene@google.com> <86wlxgy00t.wl-maz@kernel.org> <86se83xrwx.wl-maz@kernel.org> <86qznnxptx.wl-maz@kernel.org> 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 Mon, Jun 08, 2026 at 03:40:30PM +0100, Will Deacon wrote: > Hey Seb, > > On Mon, Jun 08, 2026 at 02:22:22PM +0000, Sebastian Ene wrote: > > On Fri, May 29, 2026 at 04:32:24PM +0100, Will Deacon wrote: > > > I'd probably structure it as a separate patch per call, tbh. That way, > > > the commit message can talk about the specific fields that are reserved > > > for a given call. See below. > > > > > > > Refactor the handling logic in pKVM FF-A proxy to support checking for > > > > SBZ/MBZ values. While at it, drop the do_ffa_mem_xfer macro and replace > > > > it with two functions that make it clear that we re-write the > > > > function-id with a 64-bit variant, to keep the same behavior as before. > > > > Keep each handler in an array of structures together with a mask that > > > > corresponds to the SBZ registers the spec expects. > > > > > > Although I agree that we should be enforcing SBZ/MBZ paramaters (because > > > we have no idea what they might do in future versions of the spec), I > > > also think that doing this at the register level is too coarse. > > > > > > For example, the VM ID parameter to FFA_NOTIFICATION_BITMAP_CREATE has bits > > > 31:16 as MBZ. So I think we probably need to do the checking on a > > > per-function basis, like Per is doing in his series: > > > > > > https://lore.kernel.org/r/20260501-host-direct-messages-v6-0-3f4af727ed85@google.com > > > > > > > For the newly added calls like FFA_NOTIFICATION_* we can do that in a > > separate functions, but what about the other existing calls that have > > MBZ registers ? that was the reason for the inline proposal in : > > https://lore.kernel.org/all/af3fW468-f1KXCrC@google.com/ > > (to avoid duplicate checks). > > For unused parameter registers that are SBZ, I think you could just add > a helper, e.g.: > > ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int reg); > > which takes the index of the first unused register and then checks that > all the registers from there to the last unused parameter register are > zero. You can then just call that directly before you start parsing the > SBZ/MBZ fields on the used parameter registers and there's no need for > the table-based indirection in [1]. I see, will do that, thanks. Sebastian > > Will > > [1] https://lore.kernel.org/all/af3fW468-f1KXCrC@google.com/