From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A8B37412BFC for ; Thu, 20 Aug 2026 10:09:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787220563; cv=none; b=WKkCh8DEHiQ9zwy1YrINakeQyXlwjk/rNs41eSDFGA65Q8sTIP//byDsMvz7t04sx61xIrHv6DvL7tabxsraTHmHdfC/Z992sMenRDFwsc+aRXFq/4/OG+chgLddDRXzUhOWtxKxLt9pFOWK//M+yJGWPiNOWPS45yYhtzqUQ7A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787220563; c=relaxed/simple; bh=sH2sAQhq79low0xTG+PL3gzMzDeoD9iF7DiNLRoELSI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tvM7N/yk0hdxcnbKcopTMVxxU+cEFPL2ocd+ink2DhGqDkPMWlZ0RF4uxUQyReuTOEr7vh559fBb2g+kshymmwIs+7/Bdi+t48Gjg5LkQWR9hCXb2IGX6ITfO1TxbvVmBRVK9RvVzixgX7eqtpJAQvlQz3MaXwdN7hpG8xOru8I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=IqqbY3Ln; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=LDny8B6N; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="IqqbY3Ln"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="LDny8B6N" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1787220551; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VWz7OuqsDy/FzjRS0OiNSUvLi8xeYgzLLggshpzDzkE=; b=IqqbY3Lnjo0PzkAGerxflyae4a6h1aiumlAAkQmpPWSlg16tHNWawsH9OwUfBRn9Ca9GVs TokbCajJmEzmjgwCrSlAuDac/0Vbq/MBaKgeMMp0lvEcBAKlzH0x8UPoQJXYjZOFnrTJ3q HlySW9YI2zJylrAXZ78s7ImszcGYmPQ= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-169-Ia3tdrJsO82MWmPRRgMPAA-1; Thu, 20 Aug 2026 06:09:10 -0400 X-MC-Unique: Ia3tdrJsO82MWmPRRgMPAA-1 X-Mimecast-MFC-AGG-ID: Ia3tdrJsO82MWmPRRgMPAA_1787220549 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4994aebe932so25192645e9.3 for ; Thu, 20 Aug 2026 03:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1787220549; x=1787825349; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=VWz7OuqsDy/FzjRS0OiNSUvLi8xeYgzLLggshpzDzkE=; b=LDny8B6NvpsuYb+7SJJ0xvdd579nfQzkwXto+oXmFzdOeHGJivI/ohLUHV3DrYNs0b AGsdDAgFDh3yz1vB7XpmODwHDa7uvpeAVIb0NSss+0fTsVh3mOe+EE7fxrpVQG+gJwZv XAJHEPRR17bioDhKuTjHlUJT/iETt5rcQL+rKzH80AoVpofqncC5APTTPz1YNWIP3cae omVBs7B8ZVJ2xoL5QMEfO6FjM3hU9m2PBSY58rGIGqGz5nWHYd85+Yuj2UDjFGVCsae5 IQ1hr+9QqAPOI23dfzVxRptgaFoCMKspE3WkogPWhELqHXfyuZQNasbVxFzgeajKuh2P 0VjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787220549; x=1787825349; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=VWz7OuqsDy/FzjRS0OiNSUvLi8xeYgzLLggshpzDzkE=; b=GnWvOVs4UohDO0vIZd7Dk/PHOv/WXYslaSSIX4f3MBf/EBVsPkV/sx36Zwmwp+pPnw cAjycP2eM2xfeIvv5THR5Ia96oEpPtP3OadOr6SeNtJV/MMG5xDwRR5d0fQggwzxakQO Oi/AGvalrFqobk89InAG6Zi/VXgdLS7piBKrGTJyU53MmN8rto7HCrzuxZGhtVe5gjAt R5uQZqqc/6TcEzZexHK0s+8YCrWLe4BdpidRFw0BGn6v8GPYTnmsJxghAhQtX22bH+sz qX68fNXiZLQ3xVsb1WzOwP4+io2wtfKkAYfHKuxp5Xszx5f9M2W+tVbx6XUCY3co7hqv tZmw== X-Forwarded-Encrypted: i=1; AHgh+Rrffuq16RqD/ZgiU4BwW8Ms0wgLfxEsR++cX5gwzpoPT6IqunKQcVn9KMgdDUjXXXh2aro/zahdHLozels=@vger.kernel.org X-Gm-Message-State: AOJu0YxurYoPTXcrP+2Ol8rqzKfoPmwko2gHwgJAv+NdO9Ca1SVyoeHi jfHjAcbXcUo++hdM+znJ6xaf4+FQ33ppied3UTGBUhEpYlg0QcOYQgXSDR+OuMMl27QpO5q80vP mX0L0V+gE07Ufku8x/BWZSijxgd7RgE+/tp22h/xoYp3iqeK7saF695LeY9lM2bmCXQ== X-Gm-Gg: AR+sD10mwH1zBGOYRdZih5rw3TdY3w6rdXwKl3f9bFwYpleidv4QmmCXeDIedqwNoil ib+Tyrb9PTK85Ex8mVTgXXBDgNkpn4Zrrzbb+FOFNf7/ZDNKI6v4Y7i/fBZ18pcyt4h3Af7KSLE kqCM2eHMOe86Qiohie4f4b6KF3aD0v/wzQQygR0PoOolAnkf3jCnSGgfOfd4Ytd/fC97eyzwWPr dCSnyqYYBQbwNPw/hrCrU+dO9F87eRHKIs5GuA7Ib55uoQjeRhxVNLa+icKl5OrFpns1E7jacwJ AddFNSFDi3jZSZtt2sI3ZQV9YOgKle7NYsr8UX9O+QOKoLIFjsVjEuvREkbwunS7IjTpaXtI0Sx 083a87b96U95Lb/vGDl/SEaAhS0PdoV0Bexjp+iLkuec= X-Received: by 2002:a05:600c:3553:b0:499:8156:cd3f with SMTP id 5b1f17b1804b1-499aa1b0350mr172531305e9.8.1787220549241; Thu, 20 Aug 2026 03:09:09 -0700 (PDT) X-Received: by 2002:a05:600c:3553:b0:499:8156:cd3f with SMTP id 5b1f17b1804b1-499aa1b0350mr172530735e9.8.1787220548689; Thu, 20 Aug 2026 03:09:08 -0700 (PDT) Received: from ?IPV6:2a01:e0a:f0e:9070:527b:9dff:feef:3874? ([2a01:e0a:f0e:9070:527b:9dff:feef:3874]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-499aa0dd5fcsm143802935e9.14.2026.08.20.03.09.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Aug 2026 03:09:07 -0700 (PDT) Message-ID: <78d60d96-d0c7-4eaa-b425-ca4f75263b12@redhat.com> Date: Thu, 20 Aug 2026 12:09:06 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/4] KVM: arm64: vgic-its: Free the caches when GITS_BASER changes Content-Language: en-US To: Fuad Tabba , Marc Zyngier , Oliver Upton Cc: Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Will Deacon , Sascha Bischoff , Sebastian Ene , Fuad Tabba , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260819102809.310708-1-fuad.tabba@linux.dev> <20260819102809.310708-2-fuad.tabba@linux.dev> From: Eric Auger In-Reply-To: <20260819102809.310708-2-fuad.tabba@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Fuad, On 8/19/26 12:28 PM, Fuad Tabba wrote: > A guest that disables the ITS and re-points or shrinks GITS_BASER > with VALID still set keeps the devices and collections it mapped > against the old table, as KVM frees them only when VALID is cleared. > The table format is not architected, so a write with a different value > is allowed to lose what it describes. Free the list whenever the I don't really get "a write with a different value is allowed to lose what it describes". A write at which place, in the collection table? > stored value changes. > > Test for a change rather than a write: its_restore_enable() rewrites > GITS_BASER from its probe-time cache on resume, and KVM reports > GITS_TYPER.HCC as 0, so nothing re-maps the boot CPU's collection > afterwards. > > Fixes: 36d6961c2b481 ("KVM: arm/arm64: vgic-its: Free caches when GITS_BASER Valid bit is cleared") > Suggested-by: Marc Zyngier > Link: https://lore.kernel.org/all/87ecg9owwa.wl-maz@kernel.org/ > Signed-off-by: Fuad Tabba > --- > arch/arm64/kvm/vgic/vgic-its.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c > index f6538b1976f9b..3339d9977af27 100644 > --- a/arch/arm64/kvm/vgic/vgic-its.c > +++ b/arch/arm64/kvm/vgic/vgic-its.c > @@ -1649,7 +1649,7 @@ static void vgic_mmio_write_its_baser(struct kvm *kvm, > unsigned long val) > { > const struct vgic_its_abi *abi = vgic_its_get_abi(its); > - u64 entry_size, table_type; > + u64 old, entry_size, table_type; > u64 reg, *regptr, clearbits = 0; > > /* When GITS_CTLR.Enable is 1, we ignore write accesses. */ > @@ -1672,7 +1672,9 @@ static void vgic_mmio_write_its_baser(struct kvm *kvm, > return; > } > > - reg = update_64bit_reg(*regptr, addr & 7, len, val); > + old = *regptr; > + > + reg = update_64bit_reg(old, addr & 7, len, val); > reg &= ~GITS_BASER_RO_MASK; > reg &= ~clearbits; > > @@ -1682,7 +1684,8 @@ static void vgic_mmio_write_its_baser(struct kvm *kvm, > > *regptr = reg; > > - if (!(reg & GITS_BASER_VALID)) { > + /* The ITS driver rewrites an unchanged GITS_BASER on resume. */ > + if (reg != old) { > /* Take the its_lock to prevent a race with a save/restore */ > mutex_lock(&its->its_lock); > switch (table_type) { One question: There is no vgic_its_invalidate_cache() in the function. Is it OK? Besides out of curiosity, why don't we go further and remove ite entries that refer to removed collections in vgic_its_free_collection()? Thanks Eric