Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oupton@kernel.org>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>,
	Steffen Eiden <seiden@linux.ibm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>, Will Deacon <will@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	Sebastian Ene <sebastianene@google.com>,
	kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save
Date: Wed, 5 Aug 2026 21:43:09 -0700	[thread overview]
Message-ID: <anQQ3dcbk72N1g1a@kernel.org> (raw)
In-Reply-To: <20260805093828.3626610-2-fuad.tabba@linux.dev>

Hi Fuad,

Thanks for fixing this.

On Wed, Aug 05, 2026 at 10:38:26AM +0100, Fuad Tabba wrote:
> @@ -2119,6 +2119,14 @@ static int vgic_its_save_ite(struct vgic_its *its, struct its_device *dev,
>  	u32 next_offset;
>  	u64 val;
>  
> +	/*
> +	 * MAPC with V=0 keeps the ITEs mapped but drops their collection,
> +	 * and with it the ICID. Save a zeroed entry, which the restore path
> +	 * reads back as invalid.
> +	 */
> +	if (!ite->collection)
> +		return vgic_its_write_entry_lock(its, gpa, 0ULL, ite);
> +

Writing a zero entry results in a suboptimal scan on the target,
compute_next_eventid_offset() should just skip ITEs that are known
invalid. Or better yet, we should just make the ITS emulation consistent
with the migration behavior and delete ITEs when their corresponding
collection is deleted. As you note, this is UNPRED after all :)

Thanks,
Oliver


  reply	other threads:[~2026-08-06  4:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05  9:38 [PATCH 0/3] KVM: arm64: vgic: Fixes for ITS table save and init retry Fuad Tabba
2026-08-05  9:38 ` [PATCH 1/3] KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save Fuad Tabba
2026-08-06  4:43   ` Oliver Upton [this message]
2026-08-06  7:41     ` Fuad Tabba
2026-08-05  9:38 ` [PATCH 2/3] KVM: arm64: vgic: Don't leak the SPI array when init is retried Fuad Tabba
2026-08-05  9:38 ` [PATCH 3/3] KVM: arm64: vgic-its: Don't write past the end of the collection table Fuad Tabba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=anQQ3dcbk72N1g1a@kernel.org \
    --to=oupton@kernel.org \
    --cc=fuad.tabba@linux.dev \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=sascha.bischoff@arm.com \
    --cc=sebastianene@google.com \
    --cc=seiden@linux.ibm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox