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 60E384398F5 for ; Thu, 20 Aug 2026 11:43:39 +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=1787226220; cv=none; b=ccNkT2ihKAG2kNFVMrg90v3En96bYml1G6Q6d0MlRqGayy4bYSAFD/cOMPNR2bnxqS2Mb1VvaJlR4iYRzSTGeOoJKqg5GQxm6+neWxivIxjNDE+ouQ6Vj9PVjMapmT7E9UOcf0Bu51g1tM4h1+EMx04oypJZS2+hnd00HB2cT10= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787226220; c=relaxed/simple; bh=lvZYAJXXKS9ME9YUmcZXLGRDZwZWc0ZoPKd6SW1fF8A=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=r2TS2MiT14+nw5BphYJnV04ru0dTlJrk2PX3nCvuSAa0tGKvEF0UHvf2zU8fd3EFbxNr8+x1F4LnI/e65uD42gaHin0AVnPyO2D3EpAUpEiz2BMm4gox5AxuLV9LR1gZpbdnK/6QpzRf18eMDek2BeGZIgbYHC0w51rI+czUPRE= 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=aHaUJH5Y; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=t6Xz8zeD; 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="aHaUJH5Y"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="t6Xz8zeD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1787226218; 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=E8J8pUe73FcjpALZHtnA0DHlxGQaT0qvtBA/sqVN6KQ=; b=aHaUJH5Yq3Ux2hBYS66ykSE4eIkeKZ+OvpIaNdCfl2Wf86Xgu/SrWU5TaqZPYYoQzNnKPC MYflf0m7y5pE1xz7MdVB4QpOS309pfGCwLkr4x2zVLWeeukMucuBWoDgM6HLvMLupVOjXH xkT44BIKNjSSQDrmDzhLGY/HgrG/NXo= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-5-4MCt9UfjO3CVyQ9G7LvUOw-1; Thu, 20 Aug 2026 07:43:34 -0400 X-MC-Unique: 4MCt9UfjO3CVyQ9G7LvUOw-1 X-Mimecast-MFC-AGG-ID: 4MCt9UfjO3CVyQ9G7LvUOw_1787226214 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-473ac08a6a4so1450256f8f.0 for ; Thu, 20 Aug 2026 04:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1787226213; x=1787831013; 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=E8J8pUe73FcjpALZHtnA0DHlxGQaT0qvtBA/sqVN6KQ=; b=t6Xz8zeD8m2AGCaNOYHdmAOLxzfj5ZJFWfy0yJfRzBK7fyg/h5gF6IC8t0d3KZaLpF oSkH13hQz7/jtRzUviB3VB3HmfrE2tv1nS1scPm5BU9HNqBsMTJGT+TakYK1BEtdoJRU f8M/BZrM6gGql3+r9pVqeFhyzjIf9rJsnhoWD7gbKP+cluvAS8wmERzFbRxeSabdLw+m rpRPLpvYWv8iAHTO5sWm4YHjtHxCS7BwhDKUED2V2UdiQ5iqM8AO5+BPIzTSuffcDDXH OzqTZ56JaU/rAKGaNv6PyPDUYNNsjdcmigw8xR6Q0ZvFtdYNCWPx9InruNNyG0lCEKVs ag7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787226213; x=1787831013; 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=E8J8pUe73FcjpALZHtnA0DHlxGQaT0qvtBA/sqVN6KQ=; b=rnwHQaD6FqHFkvpYfRs5+QOr0t0jwnZ2z6h3FZj3J0aYDWMnsfc0q8sFwMGOHxSi6S Rmn8e1Z7tIJIWxaeswPQeeviMdTCk76xBKSR6duE/DWVtLFF7h2AaEyY7NNjBqrANNU9 t6lU5gPuRJLFrKywhYxm7Ie57Q/izzKspPkA/65x4GPRg3WHU5Z+ZtbjXtSuHpTqX4Ho MvPkvDBwctl6b4g9rLi/ezcxC4vKo1ha/is9eDiE0dgXunoDmq0lr7J82HSzHbimUL2h g0klR4lmzf8Xt81z0nWKt3MqE9PAiKmDc1Sc4zd9QZRuqehtOraJUsv3k/HYjBtx0dvJ MjVA== X-Forwarded-Encrypted: i=1; AHgh+RoSMNK8O7J5v3R3aHQySIQK9WKXcta+aRYyDEhemEc5Kr7PXHnG+H+Sx5getIp534iUQmW/v88qEdueai4=@vger.kernel.org X-Gm-Message-State: AOJu0YyjLZhoN/6wNb3WHrAiaCGcubkIOaMSYJqJdvJkvyTlC8BPAeUu wxaGTDBZ6bsobf6tkZhtkAFDp/FRC28gBY7cSIr64QRL8IJVqXJcYaHWrF4Njuy10nZQIU2UjVi i54YYtBQQ+tOLltG9JWO8f/oEw0pGACn/CgEL65SbsN7plZmo8lYAB0495/jic0KW6g== X-Gm-Gg: AR+sD12WvD0efVD0MVg+a5cZhTACP5jCxtjGXZNqK5ExoQOAf/DyQ6HfE/ZGFar2fpt eVqqxNPqiQ2VPRIR9bw3xc2ZBPiy6ZaWoPD/0SY4FDx19zIeTV7eo1EM2aJB8jNJ3fHs2Z4qbE1 ZuSPMp1ge+TXzmezFsKGnB2hRq4/NZAIaf8viU5CLxqEXf9cRVURo+YY1s/mZpTQsKEYMRSmuI4 sSbbphSE2WlWqgXqZ7J+i16e9RYZj1TW7bEul8XRo5tojW1Imp8WNH6OI6OsQ0cSjzXAJMc3ooo GI8w8s43ZJCX0ylLzy9e7gCtUVy3hRDCZpy1m6vSu0Kvpyw4U3Fck36IL+THrLLWbYDVeVvmL4o eTM44OFz/SwWaPCSffn3TNwbJGFu+ooJNp12jYY42roI= X-Received: by 2002:a05:600c:34d1:b0:499:49f3:77b1 with SMTP id 5b1f17b1804b1-499aa14a6a6mr209174225e9.3.1787226213660; Thu, 20 Aug 2026 04:43:33 -0700 (PDT) X-Received: by 2002:a05:600c:34d1:b0:499:49f3:77b1 with SMTP id 5b1f17b1804b1-499aa14a6a6mr209173095e9.3.1787226213242; Thu, 20 Aug 2026 04:43:33 -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-499aa1111b2sm186902385e9.5.2026.08.20.04.43.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Aug 2026 04:43:32 -0700 (PDT) Message-ID: <2a65b85b-8aaf-4ee8-b797-732cb33fa139@redhat.com> Date: Thu, 20 Aug 2026 13:43:31 +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: Marc Zyngier Cc: Fuad Tabba , Oliver Upton , 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> <78d60d96-d0c7-4eaa-b425-ca4f75263b12@redhat.com> <871pbtoz7m.wl-maz@kernel.org> From: Eric Auger In-Reply-To: <871pbtoz7m.wl-maz@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 8/20/26 12:36 PM, Marc Zyngier wrote: > Hi Eric, > > On Thu, 20 Aug 2026 11:09:06 +0100, > Eric Auger wrote: >> >> 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? > > A write to the GITS_BASERn register describing the pointer to the > collection table. > > The additional clarification is that because the *content* of the > table is IMPDEF, if you point the ITS to a different location or size > in memory, then there is no guarantee that the caches (the KVM > internal data structures) are up to date. In this case, the proposed > course of action is to invalidate the caches and start afresh. OK thanks, this definitively clarifies the above sentence. > >>> 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? > > Probably not. We should make sure that the translation cache is gone > as well so that we retranslate and avoid signalling LPIs that have > undergone such invalidation. Thanks for spotting this. > >> Besides out of curiosity, why don't we go further and remove ite entries >> that refer to removed collections in vgic_its_free_collection()? > > The current policy is to keep the LPI alive as long as it is > mapped. The only thing is that we can't signal it, obviously. But it > would be legal to drop them altogether, only more work. OK > > An additional question is whether we should consider doing a reload of > the collection table or not. I'm not keen on it, but I can also see > how a guest could want to do this. Feels a bit over the top though. Agreed. Thanks Eric > > Thanks, > > M. >