From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932728AbdKGWYf (ORCPT ); Tue, 7 Nov 2017 17:24:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39282 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932587AbdKGWYe (ORCPT ); Tue, 7 Nov 2017 17:24:34 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E23DAB5C1 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=eric.auger@redhat.com Subject: Re: [PATCH v5 23/26] KVM: arm/arm64: GICv4: Prevent a VM using GICv4 from being saved To: Marc Zyngier , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org References: <20171027142855.21584-1-marc.zyngier@arm.com> <20171027142855.21584-24-marc.zyngier@arm.com> <1f75a11a-41c3-71b8-6abf-4aa2962e348e@redhat.com> <9c1e1c92-e0fa-737f-63ab-a335b93af6da@arm.com> <77d479e5-98f9-9081-a3a6-87bef1009775@redhat.com> <33f4de5f-004e-6b92-d4f6-651e536dc697@arm.com> Cc: Mark Rutland , Andre Przywara , Shameerali Kolothum Thodi , Christoffer Dall , Shanker Donthineni From: Auger Eric Message-ID: <32f1d6ae-4ab5-25e4-587d-9a51fccb955f@redhat.com> Date: Tue, 7 Nov 2017 23:24:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <33f4de5f-004e-6b92-d4f6-651e536dc697@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 07 Nov 2017 22:24:34 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi On 07/11/2017 17:34, Marc Zyngier wrote: > On 07/11/17 16:12, Auger Eric wrote: >> Hi Marc, >> >> On 07/11/2017 16:38, Marc Zyngier wrote: >>> On 07/11/17 15:24, Auger Eric wrote: >>>> Hi Marc, >>>> >>>> Hi Marc, >>>> On 27/10/2017 16:28, Marc Zyngier wrote: >>>>> The GICv4 architecture doesn't make it easy for save/restore to >>>>> work, as it doesn't give any guarantee that the pending state >>>>> is written into the pending table. >>>> >>>> I don't understand where does the limitation exactly come from. Can't we >>>> use the GICR_VPENDBASER table data? >>> You can't. None of the tables that are written by either the ITS or the >>> redistributors are architected. All you know is that there is one bit >>> per vLPI, but that's it (you don't even know which one is which). >> Oh I thought the redistributor config and pending tables were fully >> specified (6.1.2 and 6.1.3 of the spec), except the 1kB of the pending >> table. > > The property table is definitely architected. It is a lot less clear for > the pending table. The main issue is that you cannot really know when > the various bits have actually been flushed all the way from the > redistributor caches to memory to be introspected. Yes, it sucks. Oh OK the INV only guarantees the caches are consistent with the LPI config table. Maybe you could clarify the commit message with those details. So Reviewed-by: Eric Auger Thanks Eric > > Thanks, > > M. >